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Chapter  1 

Introduction 


1.1  Purpose 

This  document  describes  the  high-level  review  of  the  technical  platforms  of  a  selected  set 
of  DoD  systems  which  utilize  integrated  databases  to  satisfy  functional  requirements. 
The  purpose  of  the  review  was  twofold:  first,  to  assess  the  suitability  of  existing  tecimical 
platforms  to  serve  as  foundation  platforms  for  migration  and,  second,  to  recommend 
which,  if  any,  of  the  reviewed  databases  and  technical  platforms  could  serve  as  a 
prototype  for  a  DoD-wide  integrated  database.  Appendbc  A  contains  a  copy  of  the  Task 
Order  Description:  Acceleration  of  Cross-Functional  Database  Creation.  t*;. 

1 .2  Scope 

The  scope  of  the  review  was  limited  to  the  following  DoD  integrated  databases: 

•  Defense  Civilian  Personnel  Data  System  (DCPDS) 

•  Personnel  Data  System  (PDS) 

•  Stock  Control  System  (SCS) 

•  Requirements  Data  Bank  (RDB) 

•  DoD  Resources  Management  System  (DRMS)  -  (formerly  APCAPS) 

•  Mechanization  of  Contract  Administration  Services  (MOCAS) 

,  •  Marine  Coips  Total  Force  System  (MCTFS) 

.> 

* 

Four  Commercial  off-the-shelf  (COTS)  DBMSs  were  also  evaluated  for  comparison 
puiposes: 

•  QNCOM  Supra  2.0 

•  IBM  DB2  V2R3 

•  NCR  Sharebasem 

•  Oracle  7.0 
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1 .3  References 

DoD  Technical  Reference  Model  for  information  Management.  This  document  is 
available  from  the  Defense  Information  Systems  Agency,  Center  for  Information 
Management.  Contact  Mr.  John  Keane,  DISA-XI,  (703)  285-5323. 

DoD  Technical  Architecture  Frameworic  for  Information  Management.  This  document 
is  available  from  the  Defense  Information  Systems  Agency,  Center  for  Informatioti 
Management.  Contact  Mr.  John  Keane,  DISA-XI,  (703)  285-5323. 

Client/server  Guidelines.  This  document  is  available  from  DISA-XM,  Technical 
Integration  Services  Directorate,  Columbus,  Ohio.  Contact  Mr.  Gene  McManus,  (614) 
692-5518. 

User  Interface  Guidelines.  This  document  is  available  from  DISA-XM,  Technical 
Integration  Services  Directorate,  Columbus,  Ohio.  Contact  Mr.  Tom  Magee,  (614)  692- 
55122. 

^  . 

Finance  Workstation  Guidelines.  This  document  is  available  from  DISA-XM,  Technical 
Integration  Services  Directorate,  Columbus,  Ohio.  Contact  Mr.  Jeff  Roth,  (614)  692- 
5513. 

DoD  Human  Computer  Interface  Style  Guide.  Tliis  document  is  available  from  the 
Defense  Information  System  Agency,  Center  of  Information  Management.  Contact  Mr. 
John  Keane,  DISA-XI,  (703)285-5323. 

Finance  Near-Term  Technical  Architecture.  This  document  is  available  from  the  Defense 
Information  Systems  Agency,  Center  for  Information  Management.  Contact  Mr.  Dan 
Keary,  DISA-XE,  (703)  285-6580. 

I^nance  Migration  Strategy.  This  document  is  available  from  the  Defense  Information 
Systems  Agency,  Center  for  Information  Management.  Contact  Mr.  John  Pelszynski 
DISA-XM,  (703)  756-5518.  i 

1 

Finance  Client/Servcr  Implementation  Guidelines.  This  document  is  available  from 
DISA-XM,  Technical  Integration  Services  Directorate,  Columbus,  Ohio.  Contact  Mr. 
Gene  McManus,  (614)  692-5518.  \ 

1 

Finance  User  Interface  Style  Guide  (3270).  This  docunient  is  available  from  DISA-XM, 
Technical  Integration  Services  Directorate,  Columbus,  6hio.  Contact  Mr.  Tom  Magee, 
(614)  692-5512.  ) 

Finance  Communications  Implementation  Guidance. 
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Chapter  2 

Technical  Assessment  of  Integrated 

Databases 


2.1  Assessment  Methodology 

A  technical  attributes  survey  instrument  was  developed  and  employed  to  collect  technical 
data  about  each  existing  database  and  its  corresponding  technical  platform.  In  addition 
to  addressing  technical  features  of  the  hardware,  software,  DBMS  and  communications 
platform,  the  survey  instrument  also  covered  extent  of  DBMS  conformance  to  the  DoD 
Technical  Reference  Model  (TRI^,  extensibility  of  the  platform  to  handle  DoD-vude 
workload,  and  availability  of  acquisition  vehicles  which  could  be  used  DoD-wide  to 
acquire  additional  technical  platform  components  to  satisfy  potential  upgrades  or 
expansion.  A  copy  of  the  survey  instrument  is  included  within  the  Task  Order 
D^ription  in  Appendix  A. 

Data  was  collected  by  OTI  site  survey  teams  already  collecting  data  on  Finance  migration 
systems  or  by  telephone  or  personal  contact  with  technical  specialists  identified  by  the 
IXXIs  for  those  systems  not  surveyed  by  the  OH  teams.  COTC  DBMS  information  was 
contractor-compiled.  An  assumption  of  validity  was  made  on  the  information  provided 
by  the  POCs  and  their  designees. 

Technical  characteristic  information  for  each  DoD  system  gleaned  from  the  survey 
rgi^nses  was  assimilated  and  charted  to  a  matrix  titled  "System  Characteristics,"  to 
provide  uniform  portrayal  to  facilitate  comparison  with  the  other  reviewed  DoD  systems 
and  COTS  DBMSs.  The  resultant  populated  characteristics  matrices  are  contained  in 
Aiqrendix  B. 

COTS  Relational  Database  Information  v/as  compiled  about  the  most  current  version  of 
four  commercially  available  DBMSs,  none  of  which  is  currently  being  used  in  any  of  the 
reviewed  DoD  systems.  This  information  was  charted  to  the  COTS  Database 
Information  matrix  contained  in  Appendix  C.  The  information  was  compiled  using 
various  technical  references  and  interviews  with  colleagues  and  vendors  when  necessary, 
to  validate  assumptions  and  clarify  information.  It  was  gathered  for  presentation  at  a 
high  level  for  comparison  purposes  without  consideration  of  viability  of  use  or  as  an 
available  acquisition  vehicle.  The  four  COTS  DBMSs  selected  for  comparison  were  NCR 
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Sharebase  DI;  ORACLE  Version  6.2;  IBM  DB2  V2R3  and  CINCOM  SUPRA  Version  2.1. 

A  discussion  of  each  follows. 

NCR  Sharebase  in  was  selected  because  it  represents  the  dedicated,  standalone  database 
engine,  suitable  for  medium  size  DBMS  applications.  The  machine  is  currently 
inst'Uled  at  various  sites  within  DoD:  the  Office  of  the  Secretary  of  Defense, 
intelligence  agencies.  Air  Force  and  Navy  such  as  COMNAV-RESFCR  (SEMA).  The 
machine  is  a  proprietary  black  box  designed  for  performance  where  speed  and  query 
complexity  are  the  main  considerations.  The  machine  strictly  supports  the  ANSI/ISO 
SQL  2  standard.  The  dictionary  is  controlled  by  a  system  database  that  may  be 
accessed  with  the  proper  permissions,  by  users  or  COTS,  and  non-COTS  software. 
This  allows  interface  to  CASE  tools,  4th  Generation  Languages,  middleware,  etc.  The 
communication  link  is  usually  dedicated  to  a  host  (client)  that  serves  as  a  front  end 
terminal  server.  Client  application  software  also  resides  on  the  host.  Direct 
communication  to  several  clients  is  possible.  Installations  using  the  machine  are  reliant 
on  third-party  software  to  provide  access  to  the  SQL  parser  and  libraries  if  languages 
other  than  those  directly  supported  by  Sharebase  are  used.  Distributed  processing  is  also 
managed  by  the  client.  Security  Ls  nominal  C2  but  may  be  elevated  to  B2«.  again 
through  the  use  of  third-party  software.  The  average  number  of  concurrent  users  is 
estimated  to  be  128  bas^  on  minimum  memo.7  configuration  and  maximum  data 
storage.  The  actual  number  of  users  supported  is  a  function  based  on  75  percent  of  the 
amount  of  available  memo^.  User  capacity  may  be  further  controlled  by  modifying 
specific  boot  parameters,  available  channels  and  concurrent  processes  assigned  to  a 
user.  Contention  for  client  resources  is  minimized  by  offloading  all  the  DBMS  related 
activities  to  the  Sharebase  machine. 

The  remaining  COTS  DBMSs  reviewed  reside  on  a  host  machines  where  performance 
may  be  influenced  by  the  environment.  If  the  host  supports  general  data  processing  as 
weU  as  acting  as  host  for  the  DMBS  then  contention  for  resources  may  be  a  factor.  In 
general,  the  number  of  concurrent  users  of  the  DBMS  is  determined  by  the  host  system. 

ORACLE  supports  a  large  number  of  platforms,  being  most  popular  on  mid-range 
computers  and  PCs.  ORACLE  was  one  of  the  first  SQL-based  DBMSs.  ORACLE  is 
compliant  with  the  SQL  Standard  (FIPS  PUB  127-1)  Ada  Programming  Language. 
ORACLE  provides  a  suite  of  CASE,  financial  and  other  applications,  and  4GLs, 
SQL*Forms  and  SQL*Plus.  ORACLE  does  not  currently  provide  ANSn/SQL  2 
referwitial  integrity  nor  a  two  phase  commit.  Communication  is  supported  for  CICS  and 
three  sets  of  protocol.  Asynchronous  and  DECnet,  Xodiac,  3270PC  and  SNA,  non-SNA 
including  LU6.2.  Distributed  processing  is  supported  through  ORACLE’S  SQL*Net 
and  data  access  through  SQL*Cotmect.  Client/Server  support  is  provided  for  Intel 
80386  and  80486  technology.  Certification  for  B2  security  compliance  was  pending  at 
the  time  this  document  was  produced.  ORACLE’S  main  advantage  is  the  portability  of 
the  product  and  applications  generated  using  ORACLE’S  4/GL.  Enhancements  to 
Version  6.2  include  increased  transaction  and  productioA  throughput. 
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DB2  is  IBM’s  offering  for  use  in  IBM’s  MVS  environment.  This  DBMS  is  restricted 
to  IBM;  gateways  to  non-IBM  platforms  are  not  offered.  The  DBMS  is  not  portable 
except  to  identically  configured  systems.  IBM’s  SQL  has  been  accepted  as  the  defacto 
standard  and  is  compliant  with  ANSn/SQL2  proposr’s.  DB2  uses  a  Catalog/Directory 
for  managing  database  information.  The  catalog  is  the  interface  between  DB2,  CASE 
tools  and  other  applications  requiring  database  information.  Communication  is  based 
on  SNA  LU6.2/APPC.  Distributed  processing  is  limited  to  applications  that  support 
IBM’s  Distributed  Relational  Database  Architecture  (DRDA),  currently  DB2 
Subsystems,  SQL/DS,  Data  Manager  and  Presentation  Manager.  A  new  preconipiler 
feature  allows  DB2  to  check  SQL  syntax  for  use  on  other  SAA  RDBMS  systems.  DB2 
support  for  Remote-Unit-of-Work  (RUOW)  functions  provides  Client/Server  support 
for  the  above  DBMSs  on  VM,  AS/400  and  OS/2  systems.  Security  for  DB2  complies 
with  the  underlying  host  MVS  system  and  RACF. 

CINCOM’s  SUPRA  Version  2.1  is  a  full-functional  RDBMS.  SUPRA  addresses  the 
needs  for  high  performance,  large  volume,  online  transaction  processing  over  a  number 
of  platforms.  SUPRA  is  based  on  a  Three  Schema  Architecture  that  provides 
application  and  database  independence.  SUPRA  provides  comprehensive  ANSn/ISO 
SQL  support.  Dictionary  support  is  provided  by  the  Global  Directory,  wliich  also 
supports  the  distributed  processing.  CASE  tools  and  non-procedural  languages  are 
available  from  CENCOM,  and  via  SUPRA’s  open  interface  to  third-party  products. 
Communication  support  is  provided  for  Ethernet,  TCP/IP,  Token-Ring  LANs,  LU6.2, 
as  well  as  CICS  connectivity.  Security  information  was  not  available  at  the  time  this 
document  was  prepared. 

Several  additional  matrices  were  developed  to  facilitate  comparison  and  assessment  of  technical 
attributes,  features,  and  capabilities.  Responses  to  DoD-wide  database  survey  questions  were  charted 
to  a  single  matrix  titled  DoD-Wide  Database  Information  contained  in  Appendix  D.  Appendix  E 
contains  a  matrix  of  Acquisition  Information  compiled  from  the  responses  provided  to  sur/ey 
questions. 

Since  conformance  to  the  TRM  is  mandated  for  new  development,  a  matrix  (Appendbc  F)  of  pertinent 
partitions  of  the  DoD  Technical  Reference  Model  was  prepared.  Appropriate  information  from  the 
System  Characteristics  matrices,  the  DoD-Wide  Database  Iirformation  matrix,  and  the  COTS  Database 
Iiiformation  matrices  was  mapped  to  the  TRM  matrix  to  provide  a  consolidated  view  and  comparison 
of  reviewed  DoD  platforms,  and  to  better  assess  how  much  TRM  compliance  could  be  expected 
through  comparison  with  TRM  compliance  of  the  four  COTS  DBMSs. 

The  TRM  matrix  was  built  using  information  from  the  System  Characteristics  matrices,  the 
DoD-Wide  Database  Information  Matrix,  and  the  COTS  Database  Information  matrices.  TRM 
compliance  was  often  not  clearly  addressed  in  the  information  supplied  via  the  technical 
attributes  survey,  which  was  more  directed  to  current  requirements  and  support  for  the  target 
systems.  To  the  extent  possible,  an  attempt  was  made  to  separate  the  technical  aspects  of  the 
DBMS  from  the  surrounding  environmental  aspects. 
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DBMS  information  for  purposes  of  the  TRM  Summary  is  limited  to  information  on  the  four 
commercial  mainframe  DBMSs  which  are  central  to  mainstream  core  processing  of  reviewed 
systems: 

•  CHNCOM’s  TIS,  a  network  DBMS 

•  UNISYS’ DMS  1100,  an  hierarchical  DBMS 

•  Computer  Associates’  DATACOM/DB,  a  relational  DBMS 

•  Software  AG’s  ADABAS,  an  inverted  list  DBMS 

The  survey  identified  additional  DBMSs  (UNIFY  2000,  UNIFY,  IDS2)  which  are  shown  in  the  matrix 
for  documentation  purposes  only. 

Information  from  recognized  industry  sources  and  from  vendor-supplied  documentation  was  used  to 
supplement  information  froin  survey  responses  about  the  four  mainframe  DBMSs.  DBMSs  were 
viewed  as  independent  from  their  current  environment  and  without  knowledge  of  other  influence,  e.g. , 
degree  of  data  normalization  and  query  complexity,  contention  for  resources,  and  portability  based  on 
independence  of  data  (logical  versus  physical)  from  the  DBMS  or  the  application.  Isolating  the  DBMS 
from  the  environment  and  other  influences  was  necessary  when  reviewing  the  DBMS  omits  technical 
merits.  The  matrix  does  not  attempt  to  depict  performance  of  the  DBMS.  Environmental’ factors  such 
as  number  of  indices,  incorrect  data  normalization,  and  resource  contention  can  affect  performance. 
It  is  assumed  that  existing  systems  have  been  tuned  to  maximize  performance  efficiency. 

Areas  depicted  in  the  Compliance  with  TRM  Summary  matrix  directly  related  to  the  database  engine 
are: 

•  Data  Management,  which  encompasses  Directory /Dictionary,  DBMS  (engine). 

Remote  Data  Access 

•  Programming,  encompassing  SQL,  Ada,  CASE  Tools 

•  DBMS-controlled  Security 

Areas  considered  under  the  control/influence  of  the  environment  are: 

,4^ 

ft 

•  User  Interface  (limited  to  client/server) 

•  Network  (limited  to  Data  Communication) 

•  Security  control  related  to  the  processing  platform  or  an  application 

The  Directnry/Dictionary  column  on  the  matrix  shows  all  the  DBMSs  in  partial  compliance  with  the 
TRM  either  tluough  incorporation  of  a  Directory/Dictionary  as  part  of  the  DBMS  or  through  a  layered 
product  interfacing  with  the  DBMS.  The  IRDS  guidelines  are  not  complete  so  at  this  time  no  product 
is  in  tota.  compliance.  DBMS  compliance  to  the  TRM  model  was  based  on  the  information  supplied 
in  the  survey. 

Remote  Data  Access  between  a  single  client  and  server  was  treated,  with  respect  to  the  support  for 
this  activity,  without  regard  for  the  current  implementation  of  such  remote  access.  Survey  items 
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indicating  that  remote  access  is  being  addressed  by  the  environment  outside  the  control  of  the  DBMS 
are  shown  on  the  matrix.  Data  consistency  was  not  an  issue  considered,  the  assumption  being  that 
Level  I  consistency  was  the  norm.  That  is,  the  data  would  be  remotely  read— locally  written,  or  the 
data  read  was  a  copy  or  clone  of  the  remote  data,  and  consequently  might  not  necessarily  reflect  the 
actual  status  of  the  ^ta  at  the  instant  the  application  pnxess^  the  remote  data. 

Programming  language  support  for  SQL  and  Ada  gathered  from  the  survey  was  difficult  to  ascertain. 
In  general,  all  users  indicated  that  they  would  support  Ada  in  the  future  in  compliance  with  the  TRM. 
Although  support  for  Ada  indirectly  implies  SQL  support,  this  relationship  was  not  reflected  in  the 
survey.  The  migration  to  a  relational  environment  predisposes  the  use  of  the  defacto  standard,  SQL. 
However,  there  may  have  been  some  confusion  related  to  SQL,  since  it  was  referenced  in  the  survey 
three  ways:  first,  implied  by  the  DBMS  adherence  to  the  TRM;  second,  as  a  programming  language; 
and  third,  in  the  context  as  a  TRM  standard.  CASE  tools  were  depicted  as  to  availability  only. 
Information  on  the  degree  of  integration,  whether  bundled  with  the  DBMS  or  acquired  as  an  add-on 
or  layered  product,  was  not  readily  available  from  the  survey  in  most  cases. 

User  Interface  information  was  restricted  to  current  client/server  activities  directly  related  to  DBMS 
access.  Tiiis  was  treated  as  an  environmental  issue  due  to  the  nature  of  the  responses  tt  he  survey. 
Similarly,  Network  Services/Data  Communication  was  also  treated  as  an  environmental  issue. 

Security  as  applied  to  the  DBMS  was  taken  from  the  survey  responses.  There  was  no  attempt  to 
correlate  responses  to  the  security  compliance  of  the  DBMS  as  stipulated  by  the  vendor.  All  other 
security  issues  related  to  platform  or  application  were  considered  environmental  issues  and  charted  as 
such. 

A  set  of  characteristic  factors  was  established,  against  which  each  reviewed  system  could  be 
methodically  examined,  using  the  information  contained  in  the  populated  matrices.  These  factors 
included: 

(1)  Use  of  Commercial  DBMS  -  A  commercial  DBMS  foundation  should  provide  a  better  and  easier 
•;  migration  path  towards  an  open  systems  environment  than  custom-developed  data  management 

i^software. 

(2)  Relational  DBMS  -  A  relational  DBMS  (RDBMS)  provides  a  data  management  services 
framework  which  is  more  suitable  for  data  sharing  and  which  will  facilitate  the  interchange  or 
substitudon  of  like-fiincdon  products  or  technologies  which  may  become  available  through  new 
contracts.  For  example,  an  existing  RDBMS  might  be  replaced  by  a  database  macliine  or  some 
other  RDBMS  on  a  different  platform  without  requiring  significant  modification  of  application 
programs.  Candidate  systems  already  using  an  RDBMS,  or  that  can  be  readily  upgrad^  to  use 
one  in  a  timeframe  acceptable  to  accelerated  databa.se  implementation  targets,  will  be  better 
positioned  to  take  advantage  of  opportunities  to  incorporate  new  technologies  and  to  participate 
as  servers  in  heterogeneous  database  environments. 
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(3)  SQL  -  Stnictured  Query  Language  (SQL)  is  the  standard  language  for  providing  DBMS  services 
for  definition,  management  and  query  of  structured  data  within  a  relational  database  management 
system.  Emerging  Remote  Data  Access  standards  also  rely  upon  SQL  statements  to  specify  data 
access  requiren.ents. 

(4)  Contract  Scope  -  Existence  of  contract  vehicles  to  acquire  additional  hardware/software  to  satisfy 
DoD-Wide  expansion  was  considered  crucial,  i.e.,  acquisition  vehicles  are  needed  which  are  not 
limited  in  scope  to  acquiring  platform  components  only  within  the  service  or  agency  of  contract 
origin. 

(5)  Ada  -  Availability  of  Ada  is  considered  to  be  an  important  characteristic  since  DoD  policy 
mandates  Ada  use  for  DoD  systems  development.  Emb^ded  SQL  or  implementation  of  the  SQL 
Ada  Module  Extensions  (SAME)  would  te  an  added  benefit. 

(6)  Additional  TRM  Compliance  •  The  degree  of  compliance  with  additional  TRM  factors  was 
examined  in  comparison  with  the  degree  of  compliance  of  representative  COTS  DBMSs.  No 
single  additional  TRM  factor  was  considered  critical,  but  TRM  factors  which  are  met  by 
available  COTS  products  are  considered  more  important  than  those  for  whic^.  no  COTS 
compliance  exists  or  those  for  which  there  are  yet  no  standards  against  which  to  measure 
compliance.  A  vendor’s  commitment  to  industry  standards  was  also  considered  important.  Thus, 
a  v^or  committed  to  GOSIP  and  POSDC,  for  example,  would  be  considered  more  favorably 
than  one  not  so  committed. 

The  assessments  which  follow  below  include  a  business  overview  for  each  system,  a  description  of 

its  technical  platform,  and  a  determination  of  the  extent  to  which  the  platform  characteristics 

correiqxmd  to  the  characteristic  factors  described  above. 

2.2  Technical  Assessments 


2.2JI  Defense  CivBian  Personnel  Data  System  (DCPDS) 

* 

2.2.1.I  DCPDS  Business  Overview 

DCPDS  is  a  Corporate  Information  Management  (CIM)  migration  system.  The  Assistant  Secretary  of 
Defense  Command,  Control,  Communications  and  Intelligence  designated  the  Air  Force  Personnel 
Data  System  Civilian  (PDS-C)  as  the  interim  standard  Defense  Civilian  Personnel  Data  System 
(DCPDS).  PDS-C  is  the  civilian  persormel  module  of  the  Personnel  Data  System,  an  integrated 
system  that  also  supports  active  duty  Air  Force  Military  Personnel,  Air  and  Army  National  Guard  and 
Reserve  components. 

DCPDS  is  a  personnel  information  system  which  provides  automated  support  for  the  primary  functions 
of  human  resources  management  for  approximately  90  percent  of  the  total  DoD  civilian  population. 
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DCPDS  provides  real-time  access  to  civilian  personnel  data;  documents  personnel  actions;  and 
establishes  and  maintains  historical  data  for  planning,  analysis,  reporting,  and  forecasting.  The  system 
is  fully  operational.  The  three  services  (Army,  Air  Force  and  Navy)  are  the  primary  DoD  users. 
Other  DoD  major  organizations/activities  supported  by  DCPDS  are  Defense  Mapping  Agency  (DMA); 
the  Uniformed  Services  University  of  the  Health  Services  (USUHS);  Office,  Secretary  of  Defense 
(OSD);  DoD  Inspector  General  (DoDIG);  National  Guard  Bureau;  and  DoD  Dependent  Schools 
(DoDDS). 

Each  of  the  three  services  uses  the  Air  Force  developed  system  with  a  tailored  set  of  logical  tables  that 
implement  each  service’s  requirements  beyond  core  iiinctionality. 

Personnel  Data  System-Civilian  (PDS-C)  is  the  base  level,  real-time  personnel  system  for  the  Air 
Force.  It  supports  all  Air  Force  civilian  and  DoDDS  personnel.  Data  entry  and  data  query  are  done 
by  the  Civilian  Personnel  Office  in  an  on-line  environment.  Editing  is  done  in  accordance  with 
personnel  action  processing  policy.  Updating  occurs  during  data  entry.  At  the  completion  of  the  daily 
interactive  period,  the  End-of-Day  (EOD)  routines  are  executed  to  process  suspense  actions,  process 
ad  hoc  woridForce-level  requests,  create  interfaces  to  the  Headquarters  Air  Force  (HAF)  and  payroll 
systems,  and  perform  housekeeping  tasks.  In  addition  to  the  functional  requirements  e^blisheo  by 
non-DoD  oversight  agencies,  PDS-C  supports  various  agency-level  functions  and  processes,  and 
incorporates  many  value-added  sub-applications  in  such  areas  as  Career  Management  and  Training. 

Army  Civilian  Personnel  System  (ACPERS)  is  the  base  level,  real-time  personnel  system  for  the 
Army.  It  supports  all  Army  civilian  and  DoDDS  persormel.  Data  entry  and  data  query  are  done  by 
the  Civilian  Personnel  Office  in  an  on-line  environment.  Editing  is  done  in  accordance  with  personnel 
action  processing  policy.  Updating  occurs  during  data  entry.  At  the  completion  of  the  daily  interactive 
period,  the  End-of-Day  (EOD)  routines  are  executed  to  process  suspense  actions,  process  ad  hoc 
workforce-level  requests,  create  interfaces  to  the  Headquarters  ACPERS  and  payroll  systems,  and 
perform  housekeeping  tasks.  In  addition  to  the  functional  requirements  established  by  non-DoD 
oversight  agencies,  ACPERS  supports  various  agency-level  functions  and  processes,  and  incorporates 
many  value-added  sub-applications  in  such  areas  as  Career  Management  and  Training. 

>  I 

Nav&l  Civilian  Personnel  Data  System  (I'ICPDS)  is  the  base  level,  real-time  personnel  system  for  the 

Navy.  It  supports  all  Navy  civUian  personnel.  Data  entry  and  data  query  are  done  by  the  Civilian 
Persormel  Office  in  an  on-line  environment.  Editing  is  done  in  accordance  with  personnel  action 
processing  policy.  Updating  occurs  during  data  entry.  At  the  completion  of  the  daily  interactive 
period,  the  End-of-Day  (EOD)  oversight  agencies,  NCPDS  supports  various  agency-level  functions 
and  processes. 


2.2. 1.2  DCPDS  Technical  Platform  Description 

The  current  DCPDS  technical  platform  varies,  depending  upon  which  version  of  the  system  is 
examined.  The  Air  Force  version  (PDS-C)  runs  on  Unisys  11(X)/22(X)  mainframe  computers  which 
reside  at  Air  Force  bases  world-wide.  The  Unisys-provid^  operating  system  is  OS  1100.  The  Army 
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version  (ACPERS)  also  runs  on  Unisys  1100/2200  mainframe  computers  located  at  the  computer 
services  center  services  center  in  San  Antonio,  Texas,  while  the  Navy  version  (NCPDS)  runs  on 
Burroughs  mainframe  computers  (B4925,  B3955,  B2930)  located  at  the  Oak  Ridge  National  Laboratory 
in  Oak  Ridge,  Tennessee.  However,  the  Navy  is  in  the  process  of  migrating  its  version  to  the  Unisys 
1100/2200  hardware  platform.  This  migration  is  targeted  for  December  1993.  The  Air  Force 
provides  both  the  Army  and  the  Navy  with  software  support  maintenance  based  upon  Inter-Service 
Support  Agreements.  TTie  core  system  developed  by  the  Air  Force  and  used  in  both  the  Air  Force  and 
Aimy  versions  uses  DMS  1100,  a  CODASYL  hierarchical/network  DBMS  from  Unisys  Corporation, 
but  until  the  Navy  conversion  to  Unisys,  the  Navy  version  uses  indexed  files.  The  Air  Force 
developed  core  system  uses  a  different  table-set  designed  to  support  the  particular  requirements  of  that 
services  version.  The  three  versions  also  have  somewhat  different  communications  environments. 
Users  access  the  Air  Force  system  through  Unisys-compatible  terminals  and  Personal  Computers. 
Transactions  which  flow  to  the  corporate  level  database  use  AUTODIN.  Input  to  the  Army  Field 
ACPERS  is  accomplished  by  each  Civilian  Personnel  and  EEO  office  via  micro-computers  or  via 
W/B26  terminals  and  personal  computers  using  the  Unisys  5000/70  minicomputer  as  a  concentrator 
connected  via  a  communications  network  to  the  mainframe  computer.  Transactions  flow  from 
ACPERS  to  the  coqporate  level  database  via  a  dedicated  56KB  line  using  SNA  Net  on  a  DCP-30. 
NCPDS  uses  a  DCP-40  front  end  to  send  data  over  the  communications  network.  In  addition  to  the 
core  system,  the  Air  Force  has  developed  a  minicomputer-based  system  which  employs  a  commercial 
DBMS  to  provide  supplemental  capabilities  beyond  the  civilian  personnel  office.  The  Personnel 
Concept-m  system  uses  data  downloaded  from  the  mainframe  to  a  minicomputer  for  online  query  by 
managers.  It  also  provides  a  standardized  office  automation  package.  This  system  is  implemented  on 
AT«&T  3B2/600G  minicomputers  using  the  UNIX  operating  system  and  the  UNIFY  relational  database 
management  system. 


2.2. 1.3  DCPDS  Technical  Assessment 

The  core  DCPDS  system  does  not  employ  a  Relational  Database  Management  System,  nor  are  there 
any  near-term  plans  to  replace  the  current  DBMS  with  an  RDBMS.  Although  the  Air  Force  and 
ARN^f  versions  use  the  Unisys  DMS  1100  DBMS,  the  NAVY  version  does  not.  Several  candidate 
COTS  RDBMSs  are  being  considered  for  their  potential  for  future  transition. 

SQL  capability  does  not  exist  for  the  core  system.  Provision  of  SQL  capability  will  require 
rq)lacement  of  the  current  DBMS  with  a  relational  DBMS. 

Existing  contracts  could  be  used  to  acquire  additional  hardware  and  software  for  expansion  of  the 
current  core  system  platform  and  the  current  platform  for  the  PC-in  system.  It  is  not  known  if 
existing  contracts  for  core  system  platform  components  could  be  used  to  replace  the  current  DBMS 
with  a  relational  DBMS,  nor  is  it  known  if  the  scope  of  existing  contracts  permits  further  acquisitions 
for  use  outside  the  Air  Force.  There  are  no  existing  contracts  to  obtain  additional  hardware  and/or 
software  to  expand  the  current  headquarters  level  systems. 

Ada  is  neither  currently  supported  nor  used  for  development  of  core  system  database  applications. 
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Survey  responses  disclosed  that  the  core  system  has  very  little  compliance  to  the  DoD  Technical 
Reference  Model  while  the  more  recently  developed  PC-DI  system  has  a  high  level  of  compliance 
since  it  utilizes  a  relational  DBMS,  SQL,  and  operates  in  a  UNIX  environment. 


2.2.2  Personnel  Data  System  (PDS) 


2.2.2.1  PDS  Business  Overview 

The  Personnel  Data  System  (PDS)  is  the  Air  Force’s  integrated  Total  Force  Personnel  System.  The 
central  PDS  database.  Headquarters  Air  Force  (HAF),  maintained  at  the  Air  Force  Military  Personnel 
Center  (AFMPC),  and  base  level  databases  maintained  at  air  bases  worldwide,  contain  Active  Duty 
Military,  Civilian,  National  Guard,  Air  Force  Reserve,  Retired  Military,  and  Foreign  Nation^ 
records.  The  concept  of  storing  active  duty  and  reserve  personnel  records  on  the  same  computer 
system  (both  headquarters  and  base  level)  facilitated  activating  the  reserves  during  Operation  E)esert 
Storm  and  deactivating  them  at  its  conclusion.  The  PDS  provides  personnel  mission  support  at  all 
organizational  levels  within  the  Air  Force.  Most  civilian  personnel  transactions  originate  in  the 
Personnel  Data  System— Civilian  (PDS-C)  on  the  Base  Level  Personnel  System  (BLPS)  Md  flow  to 
the  HAF  database.  Most  military  transactions  originate  at  the  HAF  level  and  flow  to  the  Base  Level 
Military  Personnel  System  (BLMPS).  Each  month  approximately  15.6  million  Master  File  transactions 
and  145,000  PC  m  on-line  transactions  are  processed  to  keep  the  central  database  current.  In 
addition,  the  PDS  supports  about  32,000  ad  hoc  inquiries  and  processes  73,000  documents  to 
microfiche  each  month.  The  PDS  provides  complete  personnel  support  sq)aration.  Retiree  records 
are  maintained  to  support  voluntary  recall/mobilization  activity.  A  historical  file  of  all  active  duty  and 
retiree  deaths  is  also  maintained.  The  major  functions  include  recruiting  support,  training  pipeline 
management,  readiness  and  mobilization,  officer  and  airman  assignments,  promotion  board  support 
for  active  and  reserve  personnel,  performance  appraisal  administration,  retirement  processing,  and 
administration  of  mandatory  separation  programs  dictated  by  Congress. 


2.2i4.2  PDS  Technical  Platform  Description 

PDS  is  supported  by  technical  platforms  at  four  levels:  Headquarters  Air  Force  level.  Major  Command 
level.  Base  level,  and  Unit  level.  Each  level  interoperates  with  standard  data  structures  using 
hardware,  software,  and  databases  that  are  structured  to  that  level’s  functional  and  organizational 
requirements  and  envirorunent.  The  technical  platforms  supporting  the  headquarters  and  Major 
Command  levels  consist  of  DPS8000  Honeywell  systems  and  AT&T  3B2  computers  supporting 
different  size  users  populations.  The  Database  and  Transaction  Processing  Systems  are  DM-IV  and 
TP-8,  Honeywell’s  versions  of  IDS-n  Database  and  Transaction  Processing  systems.  Operating 
systems  are  GCOS  8  on  the  Honeywell  systems  and  UNIX  on  the  3B2  systems.  For  civilians, 
databases  at  the  Headquarters  and  Command  levels  aggregate  data  from  the  base  level  systems 
primarily  for  statistical  reporting  and  planning  purposes.  For  military  personnel,  most  transactions 
originate  in  the  headquarters  database  and  flow  to  the  base  level  for  confirmation.  Transactions 
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generated  at  the  base  level  are  transmitted  via  AUTODIN  at  the  end  of  each  work  day  to  update  the 
central  database. 

The  Base  Level  Personnel  System  (BLPS)  consists  of  the  Base  Level  Military'  Personnel  System 
(BLMPS)  and  its  civilian  personnel  counterpart  (PDS-C).  BLMPS  and  PDS-C  share  the  same 
technical  platform  as  described  for  the  Air  Force  developed  PDS-C  version  of  DCPDS  (see  2.2.1 
description).  Both  BLMPS  and  PDS-C  run  on  Unisys  ll()0/2200  mainframe  computers  which  reside 
at  Air  Force  bases  world-wide.  Both  BLMPS  and  PDS-C  use  DMS  1100,  a  CODASYL 
hierarchical/network  DBMS  and  the  OS  1 1(X)  operating  system  provided  by  Unisys.  Users  access  base 
level  PDS  through  Unisys-compatible  terminals  and  Z-248  Personal  Computers.  Transactions  which 
flow  between  the  base  level  database  and  the  HAF  level  database  use  AUTODIN. 

In  addition  to  the  core  system,  the  Air  Force  has  developed  a  minicomputer-based  system  which 
employs  a  commercial  DBMS  to  extend  the  automated  persoimel  functions  to  the  unit  level.  The 
Persoimel  Concqrt-in  system  uses  a  subset  database  from  the  mainframe  on  a  minicomputer  to  support 
online  query,  online  update  and  forms  generation  and  processing  by  managers  and  unit  level 
technicians.  It  also  provides  a  standardized  office  automation  package.  This  system  is  implemented 
on  AT&T  3B2/6(X)G  and  3B2/600GR  minicomputers  using  the  UNIX  operating  system  and  the  UNIFY 
relational  database  management  system.  | 


2,2.23  PDS  Technical  Assessment 
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The  core  PDS  system  (BLPS)  does  not  employ  a  Relational  Database  Management  System,  nor  are 
there  any  near-term  plans  to  replace  the  current  DBMS  with  an  RDBMS.  However,  although  several 
c-'-iidate  COTS  RDBMSs  are  being  considered  for  their  potential  for  future  transition. 

SQI  capability  does  not  exist  for  the  core  system.  Provision  of  SQL  capability  will  ^uire 
replacement  of  the  current  DBMS  with  a  relational  DBMS. 

Existing  contracts  could  be  used  to  acquire  additional  hardware  and  software  for  expansion  of  the 
curr^t  cote  system  platform  and  the  current  platform  for  the  system.  It  is  not  known  if 
existing  contracts  for  core  system  platform  components  could  be  used  to  replace  the  current  DBMS 
with  a  relational  DBMS,  nor  is  it  known  if  the  scope  of  existing  contracts  permits  further  acquisitions 
for  use  outside  the  Air  Force.  There  are  no  existing  contracts  to  obtain  additional  hardware  and/or 
software  to  expand  the  current  headquarters  level  systems. 

Ada  is  neither  currently  supported  nor  used  for  development  of  core  system  database  applications. 

Survey  responses  disclosed  that  the  core  system  has  very  little  compliance  to  the  DoD  Technical 
Reference  Model,  whereas  the  more  recently  developed  PC-DI  system  has  a  high  level  of  compliance 
since  it  utilizes  a  relational  DBMS,  SQL,  and  operates  in  a  UNIX  environment. 


Version  1.0 


Chapter  2:  Technical  Assessment  of  Integrated  Databases 


2.2.3  Stock  Control  System  (SCS) 


2.2.3.1  Business  th’erview  of  SCS 

T!ie  SCS  encompasses  three  major  functional  components:  requisition  processing  and  distribution 
management,  returns  management,  and  disposal  management.  The  requisition  processing  and 
distribution  management  component  provides  support  for  wholesale  material  management.  It  is  based 
on  the  consolidation  of  the  Air  Foice  Stock  Control  and  Distribution  System  (SC&D)  and  the  Army’s 
Requisition  Validation  (REQVAL)  system,  Equipment  Release  Priority'  System  (ERPS)  and  Major  Item 
Requisition  Validation  (MIRV)  system.  The  consolidated  system  supports  the  following  business 
functions:  the  item  manager  wholesale  requisition  process,  wholesale  management  and  efficiency 
rqxjits,  wholesale  and  retail  receiving  and  shipping,  inventory  and  storage  process,  requisition 
validation,  equipment  release  prioritization,  and  major  item  requisition  validation.  It  enables  the 
Inventory  Control  Point  and  Storage  Activities  to  share/update  information  in  a  real-time,  single  asset 
record  environment.  The  returns  management  component  consolidates  the  Air  Force  ^Recoverable 
Assembly  Management  Process  (RAMP),  the  Navy  Carcass  Tracking,  the  Navy  Master  Repairable 
Item  List  (MRIL),  and  the  Army  Material  Returns  Program  (MRP).  This  system  provides  visibility 
and  tracking  of  rq)airable  assets  down  to  the  customer  (user)  level.  The  disposal  management 
component  combines  the  Army  Disposal  Material  On-line  Requisition  System  (DMORS)  and  the 
DMORS’  Disposal  Maintenance  Batch  System  (DMBUCS)  with  the  Navy  Uniform  Inventory  Control 
Disposal  System.  The  consolidated  system  facilitates  detection  of  inactive  or  non-essential  items, 
contributing  to  the  reduction  of  DoD  inventories. 


2.2.3.2  SCS  Technical  Platform  Descripticn 

The  hardware  platform  for  SCS  consists  of  large-scale  IBM  compatible  mainframes.  The  software 
platj^l^  comprises  a  wide  range  of  IBM  and  other  COTS  products  which  run  in  the  IBM  MVS/ESA 
envmnment,  including  the  DBMS,  Datacom/DB,  a  commercial  DBMS  from  Computer  Associates, 
International,  Inc.  SCS  currently  runs  at  five  sites;  development  and  testing  is  conducted  a^  a  sixth 
site.  SCS  is  also  a  designated  migration  system  and  will  expand  its  scope  of  operations  to  serve  DLA 
and  other  services.  The  expansion  is  expected  to  result  in  dq)loyment  of  eleven  additional  physical 
databases  on  essentially  the  same  or  a  compatible  upgraded  platform.  1 


2.2.3.3  SCS  Technical  Assessment  \ 

SCS  is  supported  by  Datacom/DB,  a  modem  commercial  relational  database  management  syltem. 
Although  the  latest  version  of  the  DBMS  is  not  currently  being  used,  migration  to  the  latest  release 
is  plaimed  to  take  place  within  the  next  year. 
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The  software  platform  complies,  at  least  in  part,  with  key  aspects  of  the  DoD  Technical  Reference 
Model  although  some  of  the  capabilities  are  not  currently  being  used  by  SCS. 

ANSI  and  FIPS  SQL  are  supported  by  the  DBMS,  Out  SQL  is  not  currently  being  used  within  SCS. 
However,  it  is  anticipated  that  SQL  will  be  used  in  the  future. 

A  variety  of  contracts  either  currently  exist,  or  are  in  progress,  to  obtain  not  only  additional  copies 
of  the  DBMS,  but  also  additional  hardware,  operating  system  software  and  other  COTS  products  for 
expansion  of  the  technical  platform.  SCS  representatives  believe  that  current  contracts  could  be  used 
to  obtain  products  for  use  outside  their  component,  but  are  not  certain  what  effect  DMR918  or  other 
LMRDs  will  have  on  existing  contracts  or  future  acquisitions. 

The  Ada  programming  language  is  supported,  but  is  not  currently  being  used.  Future  use  of  Ada  is 
plarmed,  pending  necessary  funding  availability. 

The  communications  environment  for  SCS  is  currently  IBM  SNA.  DISN  will  provide  the  future 
communications  environment  for  extension  to  other  platfonns. 

The  DBMS  incorporates  an  active  dictionary/directory  which  is  used  by  SCS.  Representatives  did  not 
know  to  what  degree  the  dictionary  might  be  consistent  with  emerging  IRDS  standards.  The  DBMS 
also  allows  interface  of  C.^E  tools  to  the  database.  SCS  uses  a  commercial  CASE  product  called 
CADRE.  Data  definitions  from  C<\DRE  are  fed  into  the  active  data  dictionary  via  the  interface. 

While  not  currently  being  used  by  SCS,  a  new  CA  product  called  CA-DB:STAR  is  currently  being 
tested  by  the  government.  This  product  provides  data  distribution  services  to  multiple  Datacom 
systems,  providing  the  ability  for  applications  to  transparently  access  and  update  distributed  data  as 
if  it  were  managed  by  a  single  DBMS.  One  potential  use  for  this  product  would  allow  the  incremental 
expansion  of  databases  by  building  additional  physical  databases  on  separate  hardware  platforms 
which  become  extensions  to  the  single  logical  database,  i.e.,  the  existence  and  location  of  multiple 
physical  databases  is  transparent  to  applications  and  MIS  tools  which  access  the  logical  database.  This 
distri|Hited  operations  product  would  also  make  it  possible  for  a  single  process  to  access  multiple 
Data^m/DB  databases  built  indqrendently  at  different  locations,  even  when  the  databases  have 
different  structures  and  content. 

DBMS  security  is  currently  embedded  within  the  DBMS,  but  a  future  release  will  eliminate  the 
embedded  security  code  t^ugh  provision  of  an  interface  to  the  COTS  security  product  TOP 
SECRET. 

According  to  vendor  rqrresentatives,  the  vendor  is  committed  to  supporting  industry  standards  and  is 
actively  moving  in  the  direction  of  POSK.  The  vendor’s  products  operate  on  various  platforms  other 
than  IBM-compatible,  including  mini  and  microcomputer  platforms. 
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2.2.4  Requirements  Data  Bank  (RDB) 


2.2.4. 1  RDB  Business  Overview 

The  RDB,  currently  under  development  in  the  Air  Force,  is  a  total  system  for  supporting  requirements 
needs  for  all  items.  The  system  consists  of  a  relational  database  and  modular  programs  which  run 
indq)endently  of  the  database,  .^iplication  modules  determine  initial  and  replenishment  requirements 
for  ^  categories  of  items  including  aircraft  engines.  The  system  computes  repair  requirements  for 
all  Air  Force  items,  groups  items  into  families,  calculates  program  values  to  the  item  level,  and 
provides  item  managers  on-line  review  of  forecasts  and  buy/repair  recommendations.  The  system  sets 
controls  and  support  levels  to  control  all  inventory  actions.  The  system  contains  an  applications  and 
indenture  file  for  all  items,  relating  them  to  their  weapon  system  for  total  weapon  system 
requirements.  The  RDB  system  concept  requires  that  all  levels  of  management  share  accurate  and 
timely  logistics  information  for  strategic  planning,  tbrecasting,  management  direction  and  control  and 
operational  control  of  logistics  resources,  specifically  regarding  the  inventory  levels  needed  to  support 
readiness  capabilities.  As  data  is  processed  in  the  RDB,  it  is  updated  and  made  immediately  available 
for  use  by  various  functional  groups  at  different  locations.  The  system  concept  provicks  fiinctional 
support  to  the  requirements  processes  by  furnishing  computational  capabilities  and  detailed  information 
retrieval.  The  primary  information  de^s  with  demands,  pipelines,  inventories  and  usage  and  actiWty 
rates.  Outputs  of  the  system  appear  as  buy  quantities  and  repair  requirements.  In  addition,  budgets 
to  justify  the  dollars  needed  to  logistically  support  operations  are  provided  to  managers.  The  RDB 
system  also  provides  the  capability  to  compute  requirements  to  achieve  weapon  system  availability 
objectives  as  well  as  record  item  demands/usage  by  weapon  system. 


2.2.4.2  RDB  Technical  Platform  Description 

The  hardware  and  software  platforms  for  RDB  are  both  essentially  the  same  as  the  platforms  for  SCS, 
i.e.,  large-scale  IBM  mainframe,  Datacom/DB  DBMS  and  a  wide  range  of  ancillary  COTS  products. 
CA^  tools  used  for  RDB  are  different  from  those  used  for  SCS.  RDB  uses  a  tool  called 
Destgn/Recovery,  which  feeds  to  another  tool  called  Excelerator.  The  RDB  CASE  tools  are  not 
interfaced  to  fe^  the  dictionary,  but  Excelerator  feeds  the  Ventura  Desktop  Publishing  product  to 
publish  documentation. 


2.2.4.3  RDB  Technical  Assessment 

Since  the  technical  platform  for  RDB  is  essentially  the  same  as  the  technical  platform  for  SCS,  the 
RDB  technical  assessment  is  equivalent  with  one  significant  difference:  contracts  currently  in  place 
for  RDB  cannot  be  used  to  obtain  additional  products  for  expanded  use  outside  of  the  component. 
However,  RDB  representatives  stated  their  belief  that  DMR  924  initiatives  may  provide  the  acquisition 
scope  sufficient  to  provide  for  DoD-Wide  use.  In  addition,  since  the  platforms  are  so  much  alike,  it 
might  be  possible  to  use  SCS  acquisition  vehicles  to  supply  additional,  technical  platforms  for  RDB. 
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2.2.5  Defense  Business  Management  System  (DBMS) 


2.2.S.1  Business  Overview  of  DBMS 

Defense  Business  Management  System  is  an  integrated  system  which  supports  management  of 
cross-functional  areas  which  utilize  common  data.  This  system  consists  of  four  distinct  subsystems: 

(1)  Personnel 

(2)  Payroll 

(3)  Cost 

(4)  Appropriation  Accounting 

Data  is  input  into  the  systems  via  a  single  standard  on-line  interface,  and  validation  criteria  for  all 
subsystems  is  applied  at  that  time.  The  data  is  captured  in  an  integrated  database,  which  is  utilized 
by  all  of  the  various  subsystems.  Thus  data  is  entered  and  validated  once  for  use  by  all  subsystems, 
providing  consistency  and  reducing  personnel  support  requirements. 

Defense  Business  Management  System  has  been  designated  the  migration  system  for  DBOF/Resource 
Administration  by  OSD-C. 


2.2.5.2  Defense  Business  Management  System  Technical  Platform  Description 

The  hardware  platform  for  Defense  Business  Management  System  consists  of  medium  and  large  scale 
IBM  370/390  architecture  compatible  mainframes.  The  current  software  platform  required  for  Defense 
Business  Management  System  processing  is  IBM’s  MVS/XA  or  MVS/ESA  operating  system;  the 
commercial  DBMS  used  by  Defense  Business  Management  System  is  Cincom’s  Total  Information 
System  (TIS)  and  associated  products.  Other  IBM  and  third  party  vendor  COTS  products  are  also 
used^  complete  a  manageable  lun-time  environment.  DITSO-CO  has  been  leading  an  effort  to 
consolidate  Defense  Business  Management  System  at  two  sites,  IPC  Columbus  and  Dayton.  Defense 
Business  Management  Syste  currently  runs  on  seven  computers  at  the  two  sites.  An  acquisition  is 
underway  for  larger  mainframes  to  reduce  the  number  of  required  machines. 


2.2.5.3  Defense  Business  Management  System  Technical  Assessment 

Defense  Business  Management  System  currently  utilizes  a  network-based  commercial  database 
management  system,  Cincom’s  US.  However,  Defense  Business  Management  System  is  being 
aggressively  migrated  to  SUPRA,  Cincom’s  relational  DBMS.  Developmental  transition  to  SUPRA 
is  complete.  The  ICKl  began  11  November  1992,  with  an  estimated  completion  date  of  January  1993. 
Conversion  of  all  production  systems  is  scheduled  for  completion  by  April  1993.  Subsequently, 
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Defense  Busii^'.ss  Management  System  plans  to  n  igrate  to  the  vendor’s  latest  version,  SUPRA  2, 
which  incoipc.'ates  SQL  support. 

The  current  DBMS  (TtS)  does  not  support  SQL.  SUPRA  2  provides  support  for  ANSI  and  FTPS 
SQL. 

Contract  DCA200-92-D-0053,  awarded  3  September  1992,  allows  all  DISA  components  access  to  the 
SUPRA  2  suite  of  software.  The  contract  also  contains  provisions  for  technology  refreshment.  It  is 
anticipated  that  the  dollar  amount  of  the  contract  will  be  enlarged  to  permit  standardization  by  DISA 
AISs  on  the  SUPRA  product. 

The  Ada  programming  V mguage  is  supported  by  the  MVS/XA/ESA  -  SUPRA  2  environment,  but  is 
not  being  utilized.  Embedded  SQL  support  for  Ada  is  not  currently  supported,  but  the  vendor  states 
it  will  be  available  within  a  year.  Development  using  Ada  would  require  an  Ada  compiler  for  the 
environment  to  be  acquired  for  the  CDA,  and  run-time  libraries  for  operational  DPIs. 

The  cumnt  Cincom  DBMS  utilizes  its  own  native  transaction  processing  system.  Communications 
Monitor  (CM).  Upgrading  to  SUPRA  2  requires  that  IBM’s  Customer  Information  Control  System 
(CICS)  be  acquired  and  integrated  into  the  current  platform.  VTAM/SNA  is  an  integral  part  of  the 
MVS/XA/ESA  operating  system  environment.  IBM’s  and  Interlink’s  TCP/IP  products  are  utilized  to 
supplement  processes/communication  with  smaller  non-IBM  tier  systems. 

The  Cincom  DBMS  uses  its  own  proprietary  Dictionary/Directory.  Interfaces  to  other  COTS 
dictionary  products/CASE  tools  may  be  available,  but  current  Defense  Business  Management  System 
CASE  tools  are  not  interfaced  to  the 
DBMS. 

The  Defense  Business  Management  System  development  platform  contains  a  variety  of  CASE  tools 
including  KnowledgeWare,  PM/SS,  Case2000,  Inspector,  Recoder  and  Advantage. 

SUP^  products  are  available  in  the  UNIX/Open  Systems  environment  providing  potential  for 
migration  from  a  proprietary  environment  to  an  Open  Systems  environment. 


2.2.6  Mechanization  of  Contract  Administration  Services  (MOCAS) 


2.2.6.1  MOCAS  Business  Overview 

MOCAS  is  an  integrated  system  which  supports  the  Contract  Management  functions  performed  by  the 
Defense  Contract  Manageinent  Command  (DCMC)  and  the  contract  payment  functions  performed  by 
the  Defense  Finance  and  Accounting  Service  (DFAS).  MOCAS  Im  been  designated  as  a  Finance 
migration  system  for  Contract  Payment  and  was  recently  nominated  by  the  CIM  Procurement  Council 
as  the  migration  system  for  the  Contract  Administration  functional  areas  administered  by  the  Defense 
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Contract  Management  Command  (DCMC).  The  MOCAS  system  consists  of  nine  distinct  subsystem 

structures.  They  are  listed  as  follows: 

(1)  Contract  Maintenance  for  establishing  and  maintaining  contracts  within  the  MOCAS  system. 
Contracts  enter  the  system  either  via  online  interactive  processes  or  via  MILSCAP  transactions. 
Limited  data  may  be  obtained  via  online  inquiries  and  large  amounts  of  information  may  be 
obtained  via  delayed  inquiries  which  provide  24  hour  turnaround. 

(2)  Materiel  Control  which  tracks  and  records  contractor  performance  in  supplying  goods  and/or 
services  under  contracts  maintained  within  the  system. 

(3)  Financial  Management  which  provides  the  source  of  funds  and  the  accounts  used  to  control  the 
obligation  and  payment  of  a  contract  entered  into  the  MOCAS  system. 

(4)  Contract  Management  which  provides  direct  support  of  contract  management  functions  including 
Contract  Administration,  Property  Administration,  and  Transportation. 

(5)  Quality  Management  which  provides  tools  for  the  DCMC  Quality  Assurance  Comm^ty  to  track 
the  status  of  deficiency  reports,  provide  data  for  analytical  and  executive  information  systems, 
monitor  quality  assurance  efforts  and  provide  Quality  Assurance  Specialists  with  additional 
training  and  expertise  required  to  perform  their  duties. 

(6)  Programming  and  Technical  Support  which  provides  tracking  of  contractor  delivery 
performance,  industrial  relations  data,  industrial  preparedness  planning,  and  pre-award  survey 
reporting. 

(7)  Management  Information  which  provides  a  series  of  statistics  extracted  from  each  DCMD 
database  that  are  transmitted  electronically  for  aggregation  at  DCMC. 

(8)  System  Support  which  provides  data  and  control  suj^rt  for  all  portions  of  the  MOCAS  system, 
'including  activity  add^s  maintenance  for  maintaining  contractor  and  government  address 

•  mformation,  an  online  interactive  capability  to  maintain  attribute  data  for  contracting  officers  and 
other  personnel,  as  well  as  a  variety  of  other  applications  for  MOCAS  system  table  maintenance. 

(9)  Operations  Support  which  provides  global  support  for  the  MOCAS  operations  environment 
including  utility  programs  for  maintenance  of  database  files,  special-purpose  extracts,  and 
download  extracts.  Also  included  is  a  database  interface  through  which  ^  applications  request 
data  in  a  batch  environment.  A  contract  transfer  process  provides  for  controlled  organizational 
realignment  of  contracts  across  existing  MOCAS  database. 
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2.2. 6.2  MOCAS  Technical  Platform  Description 

The  current  core  MOCAS  system  technical  platform  is  essentially  the  same  as  the  current  Defense 
Business  Management  System  technical  platform  since  tx}th  MOCAS  and  Defense  Business 
Management  System  shar^  a  common  DLA-provided  and  supported  technical  platform  (see  2.2.S.2 
and  Appendix  B,  System  Characteristics  Charts  for  MOCAS  and  Defense  Business  Management 
System).  The  current  MOCAS  system  runs  on  IBM-compatible  mainframe  hardware  using  Cincom’s 
Networic-based  Total  Information  System  (TTS)  DBMS  and  a  variety  of  IBM  and  third  party  vendor 
COTS  products  running  under  the  MVS  operating  system.  The  development  environment  for  MOCAS 
includes  a  different  principal  CASE  tool  from  Defense  Business  Management  System  in  Texas 
Instrument’s  Information  Engineering  Facility  (lEF).  However,  EEF  has  had  limited  use  to  date  since 
it  is  a  very  recent  addition  to  the  MOCAS  CASE  software  suite. 


2.2. 6.3  MOCAS  Technical  Assessment 

Since  the  technical  platform  for  MOCAS  is  essentially  equivalent  to  the  current  Defense  Business 
Management  System  platform,  the  technical  assessment  is  also  essentially  the  same.7..  However, 
MOCAS  is  not  currently  moving  as  aggressively  as  Defense  Business  Management  System  to  migrate 
to  SUPRA,  Cincom’s  relational  DBMS.  Current  plans  are  to  migrate  to  SUPRA  1  around  1st  quarter 
of  Fy94;  apparently  there  are  no  firm  plans  yet  in  place  for  subsequent  migration  to  SUPRA  2. 

Although  responses  to  the  survey  indicated  that  contractual  vehicles  are  available  to  purchase  additional 
copies  of  the  DBMS,  operating  system  and  other  system  software  and  hardware,  there  is  some 
uncertainty  whether  existing  contracts  are  sufficient  to  acquire  aU  the  products  needed  to  migrate  to 
SUPRA  2  or  if  the  contract  scope  would  allow  use  outside  of  DLA.  If,  however,  SUPRA  2  is 
considered  to  be  an  upgrade  to  the  current  Cincom  software  suite,  then  it  is  possible  that  some  excess 
licenses  resulting  from  ongoing  consolidations  could  be  used  for  other  purposes.  If  MOCAS  CDA 
resources  become  part  of  DISA,  then  the  DISA  contract  for  the  SUPRA  2  software  suite  could 
presumably  be  used  to  acquire  the  products  need^  for  migration. 

* 

2.2.7  Marine  Corps  Total  Force  System  (MCTFS) 


2.2.7.1  Business  Overview  of  MCTFS 

The  Marine  Corps  Total  Force  System  (MCTFS)  is  jointly  supported  by  the  HQMC,  Manpower 
Information  Division  and  the  Defense  Finance  and  Accounting  Service,  Kansas  City.  MCTFS, 
scheduled  for  completion  in  October  1994,  is  a  consolidated  pay  and  personnel  system  for  both  the 
Active,  Reserve  and  Retired  components  of  the  Marine  Corps.  MCTFS  became  a  distinct  project 
under  the  Defense  Joint  Military  Pay  System  (DIMS)  in  October  1991.  MCTFS  will  merge  the 
functionality  and  data  structures  of  the  R^rve  Manpower  Management  and  Pay  System  (REMMPS) 
and  the  Joint  Uniform  military  Pay  System/Manpower  Management  System  (JUMPS/MMS)  into  a 
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single  consolidated  pay  and  personnel  system.  The  existing  active  pay  and  personnel  system, 
JUMPS/MMS,  was  chosen  to  serve  as  the  baseline  for  MCTFS  development.  JUMPS/MMS  software 
will  be  modified  to  accommodate  reserve  functionality  and  standardize  the  transaction  codes  for  active, 
reserve  and  retired  functions. 

All  Marine  Coips  pay  and  personnel  transactions  are  processed  centrally  at  the  DITSO,  Kansas  City 
Information  Processing  Center  (IPC).  There  are  approximately  80,000  -  90,000  transactions  sent  to 
Kansas  City  daily  over  the  Marine  Corps  Data  Network  (MCDN)  utilizing  long-haul  communications 
lines,  dial-up  lines,  satellite  links  and  other  forms  of  telecommunications.  Data  is  collected  at  field 
activities  by  either  the  Unit  Diary  System  (UDS)  or  the  On-Line  Diary  System  (OLD).  These  two 
systems  edit  the  field  input  and  batch  up  all  transactions  for  nightly  updating  of  the  central  Kansas  City 
database.  Update  and  edit  error  reports  are  sent  back  to  each  unit  that  submitted  transactions.  An 
extract  of  the  central  database  containing  each  unit*«  personnel  and  pay  information  is  made  available 
to  individual  unit  commanders  for  local  query  and  report  generation. 


2.2,7. 2  MCTFS  Technical  Platform  Desctiption 

V  *  *  * 

The  hardware  platform  for  the  MCTFS  located  in  Kansas  City  consists  of  large  scale  IBM  mainframes. 
The  software  platform  consists  of  a  wide  range  of  IBM  and  commercial  COTS  products  running  under 
an  MVS/XA  operating  system.  The  platform  includes  the  CICS  teleprocessing  monitor.  AD  ABAS, 
an  inverted  list  DBMS  from  Software  ^  G,  is  used  as  the  database  management  system.  Much  of  the 
application  software  is  written  in  ALC,  COBOL  n  and  ADAMINTS,  a  proprietary  Software  AG 
programming  language.  The  central  database  used  for  update  processing  consists  of  VSAM  file 
structures.  Data  is  offloaded  nightly  from  the  VSAM  files  and  placed  into  ADABAS  structures 
designed  to  satisfy  database  query  and  reporting  requirements.  Field  data  collection  and  query 
applications  are  run  on  DOS  compatible  personal  computers,  some  of  which  are  connected  to  LANs 
at  larger  sites.  Distributed  databases  are  refreshed  nightly  primarily  on  the  basis  of  a  "touched  record" 
concq}t,  i.e.,  those  records  which  are  updated  during  the  nightly  batch  update  process  are  sent  back 
to  field  locations  from  the  central  location  maintain  currency.  However,  since  not  all  updates  to  the 
centr  al  database  are  the  result  of  transactions  fed  upward  from  the  unit  level,  a  portion  of  the  entire 
database  is  also  sent  nightly  so  that  field  level  databases  are  completely  refreshed  over  a  period  of 
days. 


2.2.7.3  MCTFS  Technical  Assessment 

MCTFS  does  not  currently  use  a  commercial  relational  database  management  system  for  its 
mainstream  processing.  ADABAS  version  5. 18,  an  inverted  list  DBMS,  is  used  to  host  data  offloaded 
from  the  VSAM  files  to  provide  query  and  rqroiting  capabilities  to  users  without  impacting  production 
processing.  However,  the  MCTFS  POC  indicated  that  the  application  software  is  loosely  coupled  to 
the  database  in  that  interfaces  to  the  DBMS/file  structures  have  generally  been  isolated  to  common 
modules.  This  design  policy  should  make  replacement  of  the  data  management  engine  easier  to 
accomplish  than  if  the  access  code  were  embedded  throughout  all  application  software. 
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SQL  is  not  applicab.’e  to  either  the  mainstream  processing  utilizing  VSAM  files  nor  to  the  hierarchical 
ADABAS  DBMS  and  consequently  is  not  used.  SQL  capability  is  dependent  upon  implementation  of 
a  relational  DBMS. 

Acquisition  vehicles  do  not  exist  to  acquire  additionaL'new  DBMS  software  or  additional  copies  of 
teleprocessing  monitors,  operating  systems  or  other  software  which  would  be  needed  to  extend  the 
technical  platform. 

All  rC  applications  for  front-end  aggregation  of  tra‘isactions  at  the  Unit  level  are  developed  in  Ada. 
Ada  is  not  currently  being  used  for  mainframe  development.  However,  a  pilot  mainfranie  Ada  project 
has  recently  been  completed,  and  plans  are  in  place  to  re-engineer  a  sizable  (approximately  lOOK  lines) 
application  in  Ada  in  the  very  near 
future. 

Commercial  CASE  tools  are  not  currently  used;  however,  procurement  action  is  in  progress  to  support 
a  CASE  environment  for  Ada  applications. 

The  current  technical  platform  has  limited  compliance  with  the  DoD  Technical  Reference. Model. 
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3.1  Prototype  Recommendation  Methodology 

The  databases  platforms  which  were  assessed  for  their  technical  capability  in  Section  2 
of  this  document  were  further  considered  for  their  ability  to  serve  as  a  prototype  for  a 
DoD-wide  woiidoad. 


3.1.1  Criteria 

Each  of  the  candidates  was  considered  for  its  applicability  to  the  Platform-Only  and 
Platfonn-and-Content  ^}proaches  outlined  below.  Relevance  to  the  Software  Interface 
^)proach  was  also  considered. 

The  Prototype  question  matrix  (Appendix  G),  built  through  analysis  of  questionnaire 
re^nses  and  direct  input  from  POCs,  was  used  in  considering  whether  a  candidate 
would  be  an  accq}table  prototype. 

The  critical  elements  were:  the  extensibility  of  the  platform  to  serve  a  DoD-wide  role  and 
the  available  acquisition  vehicles  and  technical  expertise  to  accomplish  that  extension. 
In  evaluating  for  rqrlication  and  expansion  of  an  existing  database,  the  extent  to  which 
m  database  already  performed  an  integrated  role  was  also  considered. 

A  prototype  should  also  adhere  to  the  following  precepts; 

•  The  initial  prototype  should  be  implementable  in  the  near-term  and  will  be 
inquiry-only.  It  will  have  a  well-defined,  narrow  scope,  with  a  capability  for 
incremental  expansion  when  proven.  This  will  provide  the  lowest  risk 
opportunity  to  apply  integration  technology  with  minimal  disruption  of  the 
critical  ongoing  production  environment. 

•  Hie  target  DBMS  structure  is  relational  and  SQL  compatible  in  a 
client/server  configuration.  Any  prototype  should  show  movement  toward 
that  target. 
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•  Implementation  of  a  database  will  comply  with  the  migration  strategy  and  any 
other  associated  guidelines  for  the  targeted  community.  For  the  Finance 
community,  the  following  documents  apply: 

Finance  Migration  Strategy 
Finance  Technical  Architecture 
Finance  User  Interface  Style  Guide 
Finance  Client/Sen/er  Guidelines 
Finance  Communications  Guidelines 
Finance  Woricstation  Guidelines 

•  Any  prototype  will  be  driven  by  requirements  of  the  functional  community, 
and  not  be  an  exercise  in  technical  proficiency.  Data  models  for  the  database 
wiU  be  provided  by  the  functional  community. 

•  Reuse  should  be  maximized.  Hiat  is,  wherever  possible,  the  current 
investment  in  platforms,  databases,  supporting  tools,  and  technical  expertise 
should  be  capitalized,  rather  than  pursuing  a  new  start 


3.1.2  Caveats 

The  POCs  for  all  the  evaluated  databases,  except  MCTFS,  indicated  the  avai 'ability  of 
contractual  vehicles  to  support  expansion  to  a  DoD-wide  database  platform,  however, 
the  extensibility  of  both  the  RDB  and  SCS  Datacom*DB  contracts  appears  to  be 
dependent  upon  yet  to  be  awarded  DMRD  924  contracts.  It  is  also  unknown  how 
consolidations  under  DMRD  918  will  impact  contract  vehicles  in  place.  Defense 
Business  Management  System  tq)pears  to  have  the  soundest  footing  contractually,  since 
their  acquisition  vehicle  is  designated  for  DISA. 

‘pie  availability  of  technical  expertise  could  also  be  impacted  by  DMRD  initiatives,  both 
where  the  expertise  rests  in  the  contractor  community,  and  where  government  resources 
may  be  diverted  in  the  reorganization  process. 

3.2  Prototype  Approaches 

A  DoD-wide  integrated  database  can  be  constructed  logically  and  physically  in  multiple 
ways.  The  Finance  Client/Server  Guidelines  discuss  in  detail  the  various  models  across 
which  data  management  can  be  arrayed. 

This  document  discusses  three  approaches  for  maximizing  the  current  DoD  inventory  to 
develop  a  database  capable  of  satisfying  a  DoD-wide  requirement: 

•  Platfcrm-Only  Approach— the  reuse  of  an  existing  technical  platform,  but  not 

existing  database  structure  or  content 
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•  Platform-and-Content  Approach— the  reuse  of  an  existing  technical  platform 
and  its  existing  database  structure  and  content 

•  Software  Interface  Approach— the  creation  of  a  software  interface  to  existing 
databases,  leaving  the  existing  structure  and  content  unchanged 


3.2.1  Platform-Only  Approach 

The  platform-only  alternative  involves  creation  of  a  new  database  on  an  existing  technical 
platform,  without  rq}licaticn  of  the  existing  database  population.  This  avenue  would  be 
considered  if  the  platform  was  technically  superior,  and  merited  serving  an  expanded  role 
as  a  model  for  DoD-wide  databases. 

An  example  would  be  the  reuse  of  the  Requirements  Data  Bank  platform,  but  populating 
the  database  with  civilian  personnel  data  via  an  enterprise-driven  model  of  that  subject 
area  provided  by  the  functional  community.  Since  this  approach  starts  from  an  empty 
datab^,  it  provides  the  purest  opportunity  for  creation  of  an  enterprise-driven  subject 
database,  indqrendent  of  existing  application-driven  structures. 

However,  since  this  is  a  new  start,  it  would  require  mapping  to  the  new  database  schema 
a  wide  range  of  data  structures  from  multiple  disparate  databases  which  currently  serve 
the  designated  subject  area,  with  corresponding  new  or  revised  applications  to  populate 
and  maintain  the  new  database.  There  would  be  a  continuing  requirement  to  maintain 
integrity  between  all  original  and  replicated  versions  of  data. 


3.2.2  Platform  and  Content  Approach 

This  process  would  involve  reuse  of  the  technical  platform  and  replication  of  the  database 
extent,  with  subsequent  enhancement  of  the  database  by  mapping  and  adding  data 
Ihstances  ftom  other  data  structures  to  the  baseline  structure.  This  might  also  involve 
the  incremental  addition  of  new  elements  (and  their  corresponding  instances)  to  the 
database  structure.  In  this  scenario,  the  schema  of  the  existing  database  would  be  used 
and  a  mirror  copy  of  its  data  content  would  provide  the  baseline  of  the  new  database. 
Ejqxmsion  of  an  existing  database  should  be  considered  when  the  structure  and  content, 
as  well  as  the  underlying  platform,  are  of  merit. 

An  example  of  this  approach  would  be  the  rqrlication  of  the  structure  and  content  of  a 
Defense  Business  Management  System  database,  adding  additional  instances  of  data  from 
the  other  pay/personnel  systems. 

Since  this  approach  has  an  existing  database  as  its  core,  it  is  also  predicated  upon  an 
existing  schema,  which  will  be  plication  rather  than  enterprise  driven.  However,  this 
approach  does  provide  a  core  of  data  that  is  rqrlicated,  thereby  reducing  the  mapping 
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requirements.  While  the  requirement  to  maintain  integrity  between  all  original  and 
iq)licated  versions  of  data  would  remain,  the  requirement  would  be  satisfied  more  readily 
for  the  core  data. 


3.2.3  Software  Interface  Approach 

Altho'igh  outside  the  scope  of  this  task,  a  third  prototyping  alternative  exists  which  could 
be  exploited  across  any  number  of  functional  areas.  This  alternative  would  provide  a 
front-end  interface  ("middleware")  to  existing  functional  area  databases  in  order  to 
provide  the  "look  and  feel"  of  integration  to  functional  users.  The  front-end  interface 
can  take  many  forms  technically,  ranging  in  sophistication  from  a  "central  data  manager" 
which  uses  a  directory  to  locate,  access,  and  format  cross-functional  data  in  a  real-time 
environment,  to  a  data  request,  collection,  and  response  system  which  uses  existing 
utilities  from  UNIX  and  MVS  systenis  to  accq^t  information  requests,  submit  data 
gathering  jobs  remotely,  and  assemble  and  present  the  requested  information  in  a  "near 
realtime"  environment. 

Middleware  functions  through  the  compilation  of  the  following  pieces; 

•  A  global  data  management  piece  with  a  single  logical  database  for  all 
physical  databases  with  a  global  dictionary/directory 

•  Some  form  of  intelligent  query  "builder" 

•  A  common  API,  using  SQL 

•  A  gateway  or  specialized  software  application  which  accepts  a  query  for  a 
database  &  translates  it  into  language  understandable  by  the  target  DBMS 

'Jj  •  A  transport  piece  that  carries  queries  and  results  between  client  and  server 
*  via  an  agreed  upon  protocol 

1  •  Common  user  tools  that  can  map  to  or  use  SQL 

1 

In  implementations,  the  intent  is  to  provide  the  user  a  single  coherent  view  of 
information  from  disparate  platforms,  thus  providing  a  pragmatic  incremental  solution 
that  Capitalizes  existing  investments  in  legacy  applications  and  data. 

Ihis  abroach  should  be  considered  where  legacy  database  configurations  are  not  suitable 
for  pe^tuation,  but  access  to  their  content  is  critical.  It  also  provides  a  way  to  "join" 
physic^y  distinct  databases  which  utilize  the  same  DBMS. 

As  an  example  of  the  first  case,  middleware  could  be  put  in  place  to  extract  personnel 
information  from  the  DCPDS  flat  files  for  use  in  an  executive  information  system  at  the 
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enterprise  level.  An  example  of  the  latter  would  be  the  use  of  the  CA-DB:  STAR  product 
to  extract  and  synthesize  information  from  multiple  databases  running  under  the 
Datacom/DB  RDBMS. 

There  are  advantages  to  this  approach.  Since  data  is  accessed  from  its  source,  there  is 
no  rqrlicated  database,  so  the  need  to  maintain  replicated  data  is  also  removed.  It  also 
allows  for  incremental  implementation  of  an  enterprise  view  of  data;  the  integrated  data 
schema  can  be  built  from  the  enterprise  model,  and  existing  database  structures  mapped 
to  it. 

Die  disadvantage  lies  in  the  potential  to  adversely  affect  performance  by  increasing  the 
access  requirements  on  the  legacy  database.  Also,  there  is  an  extensive  amount  of 
application  tweaking  involved  to  go  to  and  from  the  middleware  "box."  Last,  this 
technology  is  much  more  advanced  in  theory  than  in  implementation,  and  current  limited 
implementations  tend  to  be  proprietary. 


3.3  Recommendations 


3.3.1  Platform-Only  Recommendations 

Both  CA-Datacom  and  Supra  2.0  would  be  technically  suitable  as  model  platforms  for 
a  new  start  database.  In  fact,  there  are  other  RDBMS  configurations  within  the  DoD, 
which  do  not  currently  contain  integrated  data  but  are  potentially  equally  viable  as 
models,  as  are  any  of  the  COTS  DBMSs  used  for  comparison.  There  is,  however,  a 
stated  migration  goal  of  minimizing  supported  platforms.  To  achieve  that  goal, 
preference  should  be  given  to  a  suitable  platform  which  already  exists  in  the  environment 
where  the  data  is  managed  rather  than  introducing  an  additional  platform.  That  is,  if 
personnel  and  payroll  data  are  to  be  integrated,  tlie  platform  upon  which  to  accomplish 
t^t  initiative  should  come,  if  possible,  from  those  that  currently  support  payroll  and 
^rsonnel  requirements.  A  new  platform  should  be  introduced  only  when  no  satisfactory 
candidate  exists  within  the  payroll  and  personnel  DBMS  configurations. 

An  example  of  the  stqjs  necessary  to  pursue  the  Platform-Only  Approach  for 
development  of  a  prototype  is  included  at  Appendix  H. 


3.3.2  Platform  and  Content  Recommendations 

SCS  and  RDB  both  employ  the  CA-Datacom  platform.  Their  databases  each  serve 
multiple  logistics  activities,  and  thus  might  be  considered  to  be  integrated  intra- 
functionally,  rather  than  cross-functionally.  In  both  cases,  they  also  indicated  that  data 
in  their  databases  might  have  potential  value  to  other  function^  areas,  but  they  are  not 
currently  serving  a  cross-functional  role  as  migration  systems.  With  the  expansion  of 
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RDB  or  SCS  beyond  its  current  Air  Force  role  to  the  other  services,  this  platform  could 
serve  as  a  prototype  for  expansion  to  encompass  a  DoD-wide  woiidoad,  albeit  an  intra- 
fiinctional  rather  than  cross-functional  one.  SCS  and  RDB  also  have  numerous 
documented  agreements  for  data  exchanges  with  other  systems,  so  there  is  an  apparent 
need  to  expand  direct  access  capability  for  these  systems. 

Defense  Business  Management  System,  on  the  other  hand,  is  a  migration  system  which 
has  an  integrated  database  currently  serving  two  distinct  operational  functions:  payroll 
and  personnel.  With  acceleration  of  prototype  implementation  as  the  critical  element. 
Defense  Business  Management  System  provides  an  integrated  baseline  from  which  to 
start. 


The  Defense  Business  Management  System  recommendation  is  contingent  upon  successful 
completion  of  their  planned  upgrade  to  the  2.0  version  of  the  Cincom  Supra  product  in 
a  timeframe  acceptable  to  accelerated  database  implementation  targets.  The  current 
configuration  is  not  considered  acceptable  for  DoD-wide  migration  purposes. 

An  example  of  the  steps  necessary  to  pursue  the  Platform-and-Content  Approaclt-tp 
development  of  a  prototype  is  included  at  Appendix  I. 


3.3.3  Software  Interface  Recommendations 

lu  order  to  prototype  a  specific  interfacing  approach,  further  technical  research  would 
be  required  in  order  to  define  alternative  methods,  ascertain  their  technical  feasibility, 
d^ermine  associated  costs,  and  relate  each  alternative  approach  to  specific  functional 
requirements  for  the  "look  and  feel"  of  integrated  data. 

There  are  numerous  ongoing  efforts  within  the  Dq)artment  of  Defense  to  pursue  the 
software  interface  or  middleware  approach.  One  example  is  the  JCALS  program.  The 
^^ce  of  Technical  Integration  recently  completed  a  draft  evaluation  of  the  reuse 
^Ikrtendal  of  the  JCALS  program,  which  specifically  addresses  the  JCALS  Global  Data 
Management  System  (GDMS)  to  access  heterogeneous  databases. 

A  review  of  the  platforms  included  in  this  survey  reveals  the  following  potential 
candidates  for  further  consideration  in  this  approach: 

•  Datacom’s  CA-DB:STAR  for  access  to  Datacom  RDBMSs. 

•  MOCAS  Contractor  Profile  subsystem,  which  currently  uses  a  government- 
developed  product,  Openlink,  to  collect  and  present  data  from  multiple 
databa^ 

•  The  expressed  requirement  for  an  enterprise  view  of  persoimei  data,  which 
is  currently  primary  located  in  flat  files 


3-6 


Version  1.0 


Chapter  3:  Prototype  Candidates  from  Database  Assessments 


If  the  Software  Interface  Approach  is  to  be  pursued,  the  steps  in  that  direction  are 
detailed  in  Appendix  J. 

3.3.4  Other  Recommendations 

The  assessments  provided  insight  into  innovative  solutions  developed  by  the  CD  As  which 
should  be  further  reviewed  for  inclusion  in  the  solution  toolkit  as  database  integration 
occurs. 

•  MCTFS  has  developed  PC  applications  in  Ada  for  the  front-end  aggregation 
of  transactions 

•  MCTFS  appears  to  be  well-positioned  as  a  candidate  for  migration  to  a  new 
database,  since  of  those  reviewed  it  had  made  a  conscious  effort  in  design 
and  development  to  confine  data  accesses  to  a  single  module. 

•  MOCAS  has  in  production  a  subsystem  named  Contractor  Profile  which  rues 
an  in-house  developed  interface  called  OpenLink  to  access  and  draw  ^ta 
from  different  databases  and  file  systems  on  different  hardware  platforms. 

•  DLA  is  currently  employing  an  in-house  developed  product  to  extract 
information  from  the  spools  which  spawn  hardcopy  reports,  and  present  that 
information  on  the  user’s  terminal  screen. 
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This  document  provides  assessments  and  prototype  recommendations  based  strictly  upon 
technical  evaluation  criteria,  and  thus  provides  an  incomplete  picture  of  database 
integration  issues.  For  example,  documentation  of  data  requirements  and  standardization 
of  data  names  are  functional  responsibilities.  However,  these  functional  issues  have 
technical  ramiflcations,  user  connectivity  and  physical  mapping  to  name  but  two,  which 
can  only  be  accurately  assessed  by  tapping  functional  knowledge  to  augment  technical 
conclusions. 

The  final  decision  on  any  prototype  candidate(s)  must  be  reached  jointly  with  the 
functional  community  to  preclude  adoption  of  a  technical  solution  that  is  unaccept^le 
functionally,  or  a  functional  solution  that  is  technically  undoable.  Additionally,  the 
acceleration  of  cross-functional  database  creation  is  b^t  achieved  by  a  marriage  of 
available  technical  capability  to  available  functional  products.  Consensus  of  the 
Amctional  and  technical  communities  is  considered  to  be  a  critical  success  factor  in  the 
selection  and  implementation  of  prototype  candidates. 
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C)ct(rt)er  09,  1992 

Technical  Suitability  and  Prototype  Evaluation  for  Integrated  Databases. 


Contractor  Responsibilities 

1.  Create  an  Evaluation  Matrix  based  on  the  current  technical  environment  for  the 
selected  DBMS  and  on  the  information  contained  in  the  DBMS  survey.  The 
Candidate  DBMS  will  be  compared  to  selected  COTS  DBMS.  The  COSTS 
DBMS  will  be  used  as  a  baseline.  The  COTS  DBMS  criteria  wiU  be  based  on 
published  specifications.  Information  in  the  TRM  will  be  mapped  to  the  survey 
and  correlated  where  possible.  If  the  information  in  the  surveys  does  not  map 
to  the  TRM,  it  will  be  a  separate  row  in  the  matrix.  An  example  is  as  follows; 


A.  Stq)s  to  produce  the  matrix  are  as  follows: 

1.  Collect  Data 

2.  Correlate  OH  data  collection  survey  with  the  TRM  Summary  Matrix 

3.  Select  COTS  DBMS 

4.  Populate  the  matrix  with  either  an  "x*  or  a  "y/n" 
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2.  Resources  required  for  this  activity  are: 

A.  Data  Base  Administrator  1  (80  Hours) 

3.  Schedule 

A.  A  draft  of  the  matrix  will  be  provided  to  the  OTI  on  10/13/92. 

B.  Completed  Matrix— TBD 


. . 
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Appendix  B 

System  Characteristics 


SYSTEM;DCPDS 

SYSTEM  CONHGURATION 


VENDOR 

UNISYS 

DATABASE  SYSTEM  NAME 

DMS  1100  Version  12R2 

FEE  STRUCTURE 

Hierarchical 

MEMORY  REQUIREMENT 

CURRENT  SIZE 

12.2  GB 

HARDWARE/OS 

UNISYS  OSl  100  SB4 

TELEPROCESSINO  MONITOR 

AVERAGE  CONCURRENT  USERS 
MAXIMUM  CONCURRENT  USERS 

500  ATITirj 

9,995  AF-Wide 

AVERAGE  TRANSACTIONS  PER  DAY 

VENDOR 

DATABASE  SYSTEM  NAME 

UNIFY  Version  1.1.1.7G/1.1.1.7GR 

FILE  STRUCTURE 

Relational 

MEMORY  REQUIREMENT 

32-64  MB 

CURRENT  SIZE 

1-2.1  GB 

HARDWARE/OS 

3B2AJNIX  3.2/ES  SVR4/ER 

TELEPROCESSINO  MONITOR 

AVERAGE  CONCURRENT  USERS 

20 

MAXIMUM  CONCURRENT  USERS 

64 

AVERAGE  TRANSACTIONS  PER  DAY 

Unknown 
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SYSTEM:  DCPDS 


APPUCATTON  ENVIRONMENT 


LANGUAGE 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

3/GL 

Ada  (3B2) 

Yes 

Yes 

Yes 

Yes 

C  (3B2) 

Yes 

Yes 

Yes 

Yes 

COBOL  (UNISYS) 

Yes 

Yes 

Yes 

Yes 

FORTRAN 

OTHER-PLl  HAF 
(BULL) 

Yes 

Yes 

4/QL 

ACCELL,  ATLAS,  FOCUS 

Yes 

Yes 

Yes 

Yes 

FORMS,  RPT 

Yes 

Yes 

Yes 

Yes 

1  APPUCATION  CODE  RESIDENCY 

MAINFRAME/MINI 

Yes 

.  . 

Yes 

PC 

Yes 

Yes 

1  SOFTWARE  INTERFACE 

COTS SAV 

Yes 

Yes 

Yes 

Yes 

NON-COTS  SAV 

Yes 

Yes 

Yes 

Yes 

1  SYSTEM  SPECmC  FUNCTION 
CALLS  USED 

Yes 

CASE  TOOLS 

CADRE’S  TEAMWORK 

UnUTEE^USED  TO  EDIT  HOST 
STRUCTURES  ON  A  PC 

None 

. 

AVAILABLE  APPUCATION 
DOCUMENTATION 

Structure  Tree 

Yes 

Progrun  Design 
Language 
— Paeudo  Code 

Yes 

Other  Structured 
Design 

Documentation 

No 
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SYSTEM;  DCPDS  (UNISYS) 
STANDARDS  COMPUANCE 


STANDARD 


SQL 


Adk 


RDA 


POSDC 


SNMP 


DISTRIBUTED  DATABASE 


CLIENT  /  SERVER 


OPERATING  SYSTEM  SECURITY 


■  SMS  SECURITY 


APPUCATION  SYSTEM  SECURITY 


DATA  ENCRYPTION 


COMMENl’ 


UNISYS  Environment 


C2-92 


C2  (DMS  1100) 


C2 


AUTODIN 


PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

tBB 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 
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SYSTEM:  DCPDS  (3B2) 


STANDARDS  COMPLIANCE 


1  STANDARD 

COMMENT 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

SQL 

Yes 

Yes 

Yes 

Yes 

Ada 

Yes 

Yes 

Yes 

Yes 

RDA 

Yes 

Yes 

POSK 

3B2  Environment 

Yes 

Yes 

Yes 

Yes 

SNMP 

1 

No 

No 

Yes 

!RDS 

i 

No 

No 

Yes 

Yes 

GOSIP 

Partial  Compliance 

IQB 

Yes 

DISTRIBUTED  DATABASE 

No 

Yes 

Yes 

1  CLIENT  /  SERVER 

No 

No 

Yes 

Yes 

1  OPERATING  SYSTEM  SECURITY 

C2-92  ! 

Yes 

No 

Yes 

Yes 

11  DBMS  SECURITY 

C2  i 

Yes 

No 

Yes 

Yes 

1  APPUCATION  SYSTEM  SECURTl'Y 

C2  ' 

Yes 

No 

Yes 

Yes 

1  DATA  ENCRYPTION 

AUTODIN  ! 

Yes 

Yes 

Yes 

Yes 
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mmmmmmmammmatmmmmmsmmmmmmmmmmmmmammmmmmmmmmmmamammmmmmmma 

SYSTEM:  FDS— HAF  (Honeywell) 

SYSTEM  CONHCURAHON 


VENDOR 

HONEYWELL  (BULL) 

DATABASE  SYSTEM  NAME 

DM  IV 

FILE  STRUCTURE 

CODASYL  STANDARD  NETWORK 

MEMORY  REQUIREMENT 

CURRENT  SIZE 

15  GB 

HARDWARE/OS 

BULL  DPSSOOO  GCOS8 

TELEPROCESSING  MONITOR 

TP-8 

AVERAGE  CONCURRENT  USERS 

200 

MAXIMUM  CONCURRENT  USERS 

750 

AVERAGE  TRANSACTIONS  PER  DAY 

80K 

.A 
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I 

SYSTEM:  PDS-BLPS  (UNISYS)/PC-m  (3B2) 


appucahon  environment 


LANGUAGE 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

3/OL 

Ada  (3B2) 

Yes 

Yes 

Yes 

Yes 

C  (3B2) 

Yes 

Yes 

Yes 

Yes 

COBOL  (UNISYS) 

Yes 

Yes 

Yes 

Yes 

FORTRAN 

OTHER-PLl  HAF 
(BULL) 

Yes 

Yes 

4/GL 

ACCELL,  ATLAS,  FOCUS 

Yes 

Yes 

Ves 

Yes 

FOCUS,  FORMS,  RPT,  SAS 

Yes 

Yes 

mm 

Yes 

APPUCATION  CODE  RESIDENCY 

MAINFRAME/MINI 

• 

Yes 

i 

••j  • 

Yes 

PC 

Yes 

i.  ' 

•1  ■ 

Yes 

1  SOFTWARE  INTERFACE 

COTSS/W 

Yes 

1 

Yes 

NON-COTS  S/W 

Yes 

1 

1 

Yes 

1  SYSTEM  SPECinC  FUNCTION 

1  CALLS  USED 

Yes 

1 . 

1 

J  CASE  TOOLS 

CADRE’S  TEAMWORK 

-1  ■  .  ■  :  .  ■ 

• 

utejite^sed  to  edit  host 

STRUCTU&S  ON  A  PC 

None 

"]■ 

AVAILABLE  APPUCATION 
DOCUMENTATION 

Structare  Tree 

Yes 

Piognuo  Design 
Language 
— Pseudo  Code 

Yes 

Other  Stnictured 
Design 

Documentation 

No 
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SYSTEM:  FDS-HAF  (Hon^weU) 
APPUCATION  ENVIRONMENT 


Appendix  B:  System  Characteristics 


PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

No 

Vo 

Yes 

Yes 

No 

No 

No 

No 

Yes 

Yes 

Yes 

Yes 

LANGUAGE 


APPUCATION  CODE  RESIDENCY 


SOFTWARE  INTERFACE 


SYSTEM  SPECmC  FUNCTION 
CALLS  USED 


CASE  TOOLS 


UnUTIES  USED  TO  EDIT  HOST 
STRUCTURES  ON  A  PC 


AVAILABLE  APPLICATION 
DOCUMENTATION 


c 


COBOL 


FORTRAN 


OTHER-PLl 


ACCELL,  ATLAS,  DESIRE 


FOCUS.  FORMS,  RPT,  SAS 


MAIN  FRAME/MINI 


PC 


COTS  SAV 


NON-COTS  SAV 


Yes 


No 


None  (?) 


Stnicture  Tree 


Program  Design  YeS 
Language 
—Pseudo  Code 


Other  Stnictured 
Design 

Documentation 


No 


Yes 


Yes  ^ 
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SYSTEM:  PDS-BLPS  (UNISYS) 
STANDARDS  COMPLIANCE 


1  STANDARD 

COMMENT 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

1  SQL 

No 

No 

Yes 

Yes 

1  ^ 

Yes 

No 

Yes 

Yes 

I 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

SNMP 

No 

No 

Yes 

Yes 

IRDS 

No 

No 

Yes 

Yes 

No 

No 

Yes  ^ 

Yes 

1  DISTRIBUTED  DATABASE 

No 

No 

No 

Yes 

Yes 

1  CLIENT  /  SERVER 

No 

No 

Yes 

Yes 

OPERATING  SYSTEM  SECURITY 

Near  C2-92 

Yes 

No 

Yes 

Yes 

DBMS  SECURITY 

C2  (DMS  1100) 

Yes 

No 

Yes 

Yes 

APPLICATION  SYSTEM  SECURITY 

C2 

Yes 

No 

Yes 

Yes 

1  DATA  ENCRYPTION 

AUTODIN 

Yes 

Yes 

Yes 

Yes 
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mmmmmmmmmmmmmmmmmmmmmmmmmmm 

SYSTEM:  PDS— PC-HI  (3B2) 

STANDARDS  COMPLIANCE 


STANDARD 

COMMENT 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

SQL 

Yes 

Yes 

Yes 

Yes 

Ada 

Yes 

Yes 

Yes 

Yes 

RDA 

Yes 

Yes 

POSDC 

3B2  Environment 

No 

Yes 

Yes 

Yes 

SNMP 

No 

No 

Yes 

Yes  ■ 

KDS 

No 

No 

Yes 

Yes 

GOSIP 

Partial  Compliance 

Yes 

Yes 

DISTRIBUTED  DATABASE 

No 

Yes 

Yes 

CLIENT  /  SERVER 

No 

No 

Yes 

Yes 

OPERATING  SYSTEM  SECURITY 

C2-92 

Yes 

No 

Yes 

Yes 

1  DBMS  SECURITY 

Cl 

Yes 

No 

Yes 

Yes 

1  APPUCATON  SYSTEM  SECURITY 

Cl 

Yes 

No 

Yes 

Yes 

1  DATA  ENCRYPTION 

AUTODIN 

Yes 

. 

Yes 

. 

Yes 

Yes  1 

> 
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SYSTEM:  PDS-HAF  (HoneyweU) 
STANDARDS  COMPLIANCE 


PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

No 

No 

No 

No 

No 

No 

Yes  ^ 

Yes 

No 

No 

Yes 

Yes 

No 

No 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

standard 


SQL  . 


Ada 


RDA 


POSK 


SNMP 


IRDS 


IP 


DISTRIBUTED  DATABASE 


CLIENT  /  SERVER 


OPERATING  SYSTEM  SECURITY 


DBMS  SECURITY 


APPUCATION  SYSTEM  SECURITY 


DATA  ENCRYPTION 


COMMENT 


Near  C2-92 


C2 


C2 


AUTODIN 


B- 
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SYSTEM;  SCS 


SYSTEM  CONHGURATION 


Version  1.0 
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SYSTEM:  SCS 

APPUCATION  ENVIRONMENT 


LANGUAGE 


4/GL 


APPUCATION  CODE  RESIDENCY 


SOFTWARE  INTERFACE 


SYSTEM  SPECEFIC  FUNCTION 
CALLS  USED 


CASE  TOOLS 


murriEs  used  to  edit  host 

STRUCTURES  ON  A  PC 


AVAILABi^  APPUCATION 
DOCUMENTATION 


Ada 


C 


COBOL 


FORTRAN 


OTHER  -PLl 


—ASSEMBLER 


IDEAL 


MAINFRAME/MINI 


PC 


COTS  S/W 


NON-COTS  S/W 


None 


CADRE’S  TEAMWORK 

CACASELINK 

CATELON 


DATACOM/PC 


Structure  Tree  ^ 


Program  Design  Yes 
Language 
—Pseudo  Code 


Other  Structured  Yes 
Design 

Documentation 


PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

Yes 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

No 

Yes 

No 

Yes 

No 

Yes 

No 

Yes 

No 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

ssrmisKSiiSS: 
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SYSTEM:  SCS 


STANDARDS  COMPLIANCE 


STANDARD 

COMMENT 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

SQL  . 

No 

Yes 

Yes 

Yes 

Ada 

No 

Yes 

Yes 

Yes 

RDA 

Not  to  Standard 

No 

Yes 

POSIX 

No 

Yes 

SNMP 

1  IRDS 

aCS  (SNA) 

# 

1  DISTRIBUTED  DATABASE 

No 

Yes 

Yes 

Yes 

y  CLIENT  /  SERVER 

No 

No 

OPERATING  SYSTEM  SECURITY 

C2 

Yes 

Yes 

Yes 

DBMS  SECURITY 

CA’s  TOP  SECRET 

Yes 

Yes 

Yes 

1  APPUCATION  SYSTEM  SECURITY 

Near  C2-92 

Yes 

I  DATA  ENCRYPTION 

CICS  &.  Application  EXIT 

No 

Yes 

No 

Yes 

* 
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SYSTEM:  Defense  Business  Management  System 
SYSTEM  CONHGURATION 


VENDOR 

CINCOM 

DATABASE  SYSTEM  NAME 

US  Version  1.6 

FILE  STRUCTURE 

Networic 

MEMORY  REQUIREMENT 

11  MB  (Largest) 

CURRENT  SIZE 

3  GB 

HARDWARE/OS 

AMDAHL  Series  5880/MVS-XA 

TELEPROCESSING  MONITOR 

CINCOM  CM  Version  1.6 

AVERAGE  CONCURRENT  USERS 

300 

MAXIMUM  CONCURRENT  USERS 

2,000 

AVERAGE  TRANSACTIONS  PER  DAY 

100,000 

VENDOR 

CINCOM 

DATABASE  SYSTEM  NAME 

SUPRA  Version 

FILE  STRUCTURE 

Relationai 

MEMORY  REQUIREMENT 

CURRENT  SIZE 

HARDWARE/OS 

IBM  Compatible  Series  3090/MVS-XA 

TELEPROCESSING  MONITOR 

CINCOM  CM  Version  1.6 

AVERAGE  CONCURRENT  USERS 

500 

MAXIMUM  CONCURRENT  USERS 

5,000 

AVERAGE  TRANSACTIONS  PER  DAY 
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SYSTEM:  Defense  Business  Managonent  System 
APPUCATTON  ENVIRONMENT 


LANGUAGE 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

3/GL 

Ada 

No 

No 

Yes 

Yes 

C 

Yes 

Yes 

Yes 

Yes 

COBOL 

Yes 

Yes 

Yes 

Yes 

FORIRAN 

OTHER  -BASIC 

Yes 

Yes 

To  1995 

-SQL 

Yes 

Yes 

4/GL 

MANTIS 

Yes 

Yes 

Yes 

Yes 

ACCELL 

Yes 

Yes 

Yes 

Yes 

APPUCATION  CODE  RESIDENCY 

MAINFRAME/MINI 

Yes 

Yes 

PC 

Yes 

Yes 

SOFTWARE  INTERFACE 

COTSS/W 

Yes 

Yes 

Yes 

Yes 

NON  COTS  SAV 

Yes 

Yes 

Yes 

Yes 

SYSTEM  SPECIFIC  FUNCTION 
CALLS  USED 

CASE  TOOLS 

Knowledgeware,  PM/SS 

CASE  2000, 

AD/ADVANTAGE 

INSPECTION  RECORDER 

ununEs  USES  to  edit  host 

STRUCTURES  ON  A  PC 

None 

AVAILABLE  APPUCATION 

Structure  Tree 

Partial 

DUCUMsNTATlON 

Program  Design 
Language 
—Pseudo  Code 

Partial 

Other  Structured 
Design 

Documentation 

Partial 
(see  Note) 

NQiii:  Available  docuoentation  includes  Decomposition  Diagrams,  DFDs,  Structure  Charts,  Module  Action  Diagrams, 

Logical  and  Physical  Entity  Relationship  Diagrams  and  reusable  specifications  and  program  modules. 
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SYSTEM:  Defense  Business  Management  System 
STANDARDS  COMPLIANCE 


STANDARD 

COMMENT 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

1  SQL 

Yes 

Yes 

Yes 

Yes 

No 

No 

RDA 

No 

No 

Yes 

Yes 

POSDC 

Yes 

Yes 

Yes 

Yes 

SNMP 

No 

No 

No 

No 

IRDS 

No 

No 

GOSIP 

Partial  Compliance 

DISTRIBUTED  DATABASE 

No 

No 

Yes 

CLIENT  /  SERVER 

OPERATING  SYSTEM  SECURITY 

C2 

Yes 

DBMS  SECURITY 

Near  C2-92 

Yes 

Yes 

Yes 

APPUCATION  SYSTEM  SECURITY 

Near  C2-92 

Yes 

Yes 

Yes 

DATA  ENCRYPTION 

Yes 

Yes 

Yes 

Yes 
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SYSTEM:  MOCAS 
SYSTEM  CONHGURATION 


VENDOR 

CINCOM 

DATABASE  SYSTEM  NAME 

US  Version  1.6 

FILE  STRUCTURE 

Network 

MEMORY  REQUIREMENT 

10.5  MB  (Largest) 

CURRENT  SIZE 

30  GB 

HARDWARE/OS 

AMDAHL  Series  580/MVS-XA 

TELEPROCESSING  MONITOR 

CINCOM  CM  Version  1.6 

AVERAGE  CONCURRENT  USERS 

1,010 

MAXIMUM  CONCURRENT  USERS 

1,500 

AVERAGE  TRANSACTIONS  /  DAY 

360,000 

VENDOR 

CINCOM 

DATABASE  SYSTEM  NAME 

SUPRA  Version  1.3 

FILE  STRUCTURE 

Relational 

MEMORY  REQUIREMENT 

CURRENT  SIZE 

HARDWARE/OS 

AMDAHL  Series  5995/MVS-ESA 

TELEPROCESSING  MONITOR 

CINCOM  CM  Version  1.6 

AVERAGE  CONCURRENT  USERS 

1,500 

MAXIMUM  CONCURRENT  USERS 

6,000 

AVERAGE  TRANSACTIONS  PER  DAY 
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SYSTEM;  MOCAS 
APPUCATION  ENVIRONMENT 


Appendix  B:  System  Charaaeristics 


LANGUAGE 


APPLICATION  CODE  RESIDENCY 


SOFTWARE  INTERFACE 


SYSTEM  SPECEFIC  FUNCTION 
CALLS  USED 


CASE  TOOLS 


UnUTIES  USED  TO  EDIT  HOST 
STRUCTURES  ON  A  PC 


AVAILABLE  APPLICATION 
DOCUMENTATION 


Ada 


C 


COBOL 


FORTRAN 


OTHER  —  SQL 


MANTIS 


ACCELL 


MAINFRAME/MINI 


PC 


COTS  SAV 


NON-COTS  SAV 


None 


Texas  Instrument’s  lEF 


PC/NFS,  FTP,  FT/TSO 


Structure  Tree 


Prognun  Design 
Language 
—Pseudo  Code 


Other  Structured  No 
Design 

Documenfauion 


PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

No 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 
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SYSTEM:  MOCAS 


STANDARDS  COMPLIANCE 


STANDARD 

COMMENT 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

SQL 

No 

No 

Yes 

Yes 

1  Ada 

No 

No 

Yes 

Yes 

1  kda 

No  known  requirement 

No 

No 

No 

1  POSK 

No 

No 

Yes 

Yes 

1  SNMP 

No 

No 

1  IRDS 

No 

No 

Partial  Compliance 

1  DISTRIBUTED  DATABASE 

No 

No 

Yes 

1  CLIENT  /  SERVER 

3B2/IBM  MVS 

PC/3B2 

Yes 

Yes 

Yes 

Yes 

OPERATING  SYSTEM  SECURTTY 

C2 

No 

DBMS  SECURITY 

Near  C2-92 

Yes 

Yes 

Yes 

APPUCATION  SYSTEM  SECURITY 

Near  C2-92 

Yes 

Yes 

Yes 

DATA  ENCRYPTION 

AUTODIN 

Yes 

Yes 

Yes 

Yes 
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SYSTEM:  MCTFS 
SYSTEM  CONHCURAHON 


VENDOR 

Software  AG 

DATABASE  SYSTEM  NAME 

ADABAS  Version  5.18 

FILE  STRUCTURE 

Inverted  list 

MEMORY  REQUIREMENT 

10  MB 

CURRENT  SIZE 

55  GB 

HARDWARE/OS 

3090/MVS-XA 

TELEPROCESSING  MONITOR 

acs  1.7 

AVERAGE  CONCURRENT  USERS 

150 

MAXIMUM  CONCURRENT  USERS 

SCO 

AVERAGE  TRANSACTIONS  PER  DAY 

7  Million 

mam 
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SYSTEM:  MCTFS 

APPUCATTON  ENVIRONMENT 


1  LANGUAGE 

Ada 

C 

COBOL 

FORTRAN 

OTHER  -ALC 

1 

NATURAL 

1 

FOCUS 

1  APPUCATION  CODE  RESIDENCY 

MAINFRAME/MINI 

1 

PC 

1  SOFTWARE  INTERFACE 

COTS  SAV 

1 

NON-COTS  S/W 

1  SYSTEM  SPECinC  FUNCTION 
CALLS  USED 

Yes 

CASE  TOOLS 

Not  specified 

UnUnES  USED  to  edit  host 
STRUCTURES  ON  A  PC 

None 

AVAILABLE  APPLICATION 

Stnicture  Tree 

No 

DOCUMENTATION 

Profimm  Detifn 
Lanfuie 
— PseadoCode 

No 

Other  Stnctared 
DeetfB 

Docuoieiitatioa 

Yc5 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

Yes 

Yes 

Yes 

Yes 
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SYSTEM;  MCTFS 


STANDARDS  COMPLIANCE 


STANDARD 

COMMENT 

PRESENT 

FUTURE 

Required 

Supported 

Required 

Supported 

SQL 

No 

No 

Yes 

Yes 

Ada 

Yes 

Yes 

RDA 

No 

No 

No 

No 

Yes 

Yes 

1  SNMP 

No 

No 

Yes 

Yes 

1  IRDS 

No 

Yes 

Yes 

Not  Compliant 

1  DISTRIBUTED  DATABASE 

Yes 

Yes 

Yes 

Yes 

1  CLIENT  /  SERVER 

No 

No 

1  OPERATING  SYSTEM  SECURITY 

a 

Yes 

Yes 

Yes 

1  DBMS  SECURITY 

C2 

Yes 

Yes 

Yes 

1  APPUCATION  SYSTEM  SECURITY 

1  DATA  ENCRYPTION 

No 

No 

No 

No 
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COTS  Database  Informatioii 


Appendix  C:  COTS  Database  Irtformation 


Appendix  D 

DoD-Wide  Database  Information 


Appendix  D:  DoD  Wde  Database  Ir^ormatlmt 


Appendix  E 


Exiiting  License(i)  Renewibte 


Appendix  F 

Compliance  with  DoD  TRM  Summary 


F  Future 


Appendix  F:  Compliance  with  DoD  TRM  Si 
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responsibility  of  CUNET  HW/SW 
interfacing  with  SHAREBASE 
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Prototype  Information 
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Appendix  H 

Appendix  of  Steps  for  Platform-Only 

Approach 


Determine  subject  area  for  database 
Determine  user  access/connectivity  requirements 
Select  a  platform 
Select  a  site 

Assimilate  necessary  hardware/software 

Create  physical  schema  for  database  from  logical  model  provided  by  functional 
community 

Determine  current  data  sources  to  be  used  to  populate  the  database 
Map  current  data  sources  to  new  database  schema 

Determine  methods  to  be  used  to  populate/refresh  the  database.  Method  should  follow 
data  exchange  standards. 

Provide  initial  query  capability  based  upon  functional  requirement  that  conforms  with 
workstation,  communication,  user  interface  guidance. 

If  proven,  incrementally  add  to  database  content,  query  capability,  and  user  base,  based 
upon  functional  prioritization. 
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Appendix  I 

Appendix  of  Steps  for  Platform  and 
Content  Approach 


r<etermine  technical  platform  and  core  database  to  be  used  as  baseline,  driven  by 
requirement  of  functional  community 

Determine  site  where  expanded  database  will  be  prototyped 

Designate  CDA  to  be  responsible  for  prototype  effort 

Determine  user  connectivity  requirements 

Assimilate  necessary  hardware/software  (by  procurement  or  MOU  for  use) 

Establish  technical  platform  which  conforms  to  or  progresses  towards  client/server 
guidance 

Create  mirror  copy  of  core  database  on  selected  platform,  based  on  models  from 
functional  and  operational  communities 

Determine  additional  data  sources  to  be  added  to  the  core  database. 

Determine  methods  to  be  used  to  populate/refresh  the  database.  Method  should  follow 
data  exchange  standards. 

Provide  initial  query  capability  based  upon  functional  requirement  that  conforms  with 
workstation,  communication,  user  interface  guidance. 

If  proven,  incrementally  add  to  database  content,  query  capability,  and  user  base,  based 
upon  functional  prioritization. 
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Appendix  J 

Appendix  of  Steps  for  Software 
Interface  Approach 


1 .  Review  currently  ongoing  middleware  eifforts,  including  but  not  limited  to  JCALS, 
Carnot  Project,  Honeywell,  Hughes,  with  the  intent  of  learning: 

•  Methodologies 

•  Components 

•  Available  contractual  vehicles  for  components  and  expertise 

2.  Determine  viable  candidates  from  target  community.  Initial  candidates  should  be 
small,  well-defined,  and  narrow  in  scope. 

3.  Seek  out  windows  of  opportunity  to  incorporate  DoD  integrated  database 
requirements  into  ongoing  middleware  projects. 


J-1 


Appendix  K 

Lessons  Learned 


Survey  Instrument 

•  The  questionnaire  should  be  revisited  and  revised,  where  appropriate,  prior 
to  any  further  assessments. 

•  Many  questions  were  ambiguous.  Some  questions  were  pulled  from  the 
Finance  Migration  surveys,  and  did  not  serve  as  well  to  cull  out  database 
information  as  they  may  have  for  the  more  generalized  requirements  of  the 
Finance  teams. 

•  Questions  of  the  Present/Future/Required/Supported  format  were  confusing, 
and  the  responses  varied.  For  exam~te,  did  required  mean  "had  to  use,"  as 
in  the  Ada  mandate,  or  what  the  local  site  required,  or  what  the  DBMS 
required,  or  a  functional  requirement?  This  inconsistency  in  responses  led 
to  difficulty  in  the  construction  of  both  the  format  and  content  of  the 
matrices. 

•  There  was  confusion  in  framing  responses  on  capabilities  of  the  DBMS.  For 
example,  in  some  cases,  it  was  unclear  wh^her  the  question  addressed  what 
the  DBMS  was  capable  of  supporting  or  what  the  platform  put  in  place  by 
the  organization  was  supporting.  Deriving  consistent  matrix  content  in  this 
area  was  d'flcult. 

•  SQL  was  referenced  in  three  different  ways  in  the  survey:  as  a  programming 
language,  relative  to  the  DBMS,  and  in  context  as  a  standard.  SQL  questions 
need  to  be  reworked  and  regrouped  in  a  single  focus  area  of  the  survey. 

•  Additional  questions  need  to  be  added  to  the  survey  which  more  clearly  focus 
on  the  following  areas: 

data  standardization  and  documentation 
current  methods  to  handle  data  access  and  exchange 
application  issues  (modularity,  complexity...) 
age  and  stability  of  system 
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Append  K:  Lessons  Learned 


Surveyor?. 

•  There  were  four  different  surveyors/survey  teams  for  the  seven  database 
platforms  in  this  initial  study.  Interpretation  of  questions  was  not  consistent 
across  the  teams. 

•  Prior  to  any  future  assessments,  all  interviewers  need  to  jointly  review  and 
reach  a  common  understanding/inteipretation  of  all  survey  questions.  Future 
surveyors  should  have  a  common  "script"  to  accompany  the  survey, 

•  Consideration  should  be  given  to  adding  a  functional  component  and 
proponent  to  the  survey 

Matrices 

•  Development  of  matrices  led  to  the  conclusion  that  some  questions  were 
irrelevant  and  they  were  dropped.  On  the  other  hand,  some  information 
which  seemed  to  fit  the  matrix  category  was  not  requested  in  the  survey. 

•  The  TRM  conformance  matrix  was  the  most  complex  to  develop.  An  effort 
was  made  to  conform  to  the  model  developed  for  the  RCAS  evaluation,  but 
difficulties  quickly  surfaced.  Some  of  the  areas  covered  in  the  RCAS 
evaluation  were  not  specifically  covered  in  this  database  assessment. 
However,  an  Environment  block  was  added  for  each  of  the  platforms 
evaluated  to  cover  TRM  areas  not  attributable  to  the  database,  but  about 
which  sufficient  information  had  been  gathered  to  extrapolate  a  TRM 
compliance  indication. 

Furthermore,  the  issue  of  how  to  credit  compliance  was  not  clear  cut.  In 
many  cases,  the  technical  platform  of  the  system  had  the  capability  to  support 
some  aspect  of  the  Technical  Reference  Model,  but  the  system  did  not 
implement  that  feature.  Since  the  platform  was  being  evaluated  for  reuse, 
liberal  weight  was  given  to  ability  to  provide  support,  even  though  it  was  not 
currently  implemented. 


Process 


•  In  the  attempt  to  achieve  a  speedy  turnaround  on  the  survey,  insufficient 
groundworic  was  laid  with  the  POCs  who  actually  responded  to  the  surveys. 
There  was  confusion  as  to  the  intent  of  the  database  survey,  particularly 
where  surveys  were  conducted  in  parallel  with  the  ongoing  Finance  team 
surveys. 
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Appendix  K:  Lessons  Learned 


•  All  respondents  were  forwarded  a  copy  of  text  and  matrices  for  their  system 
to  review  for  accuracy.  Although  this  was  time  consuming,  this  step  was 
considered  critical. 
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